Network Support Library/RoseWare - Network Support Library.iso/pressgen/laninf.exe/MANUAL.TRN

Text File | 1993-06-10 | 654KB | 10,891 lines

 1.0 INTRODUCTION   . . . . . . . . . . . . . . . . . . . . . . . . . .  G066881
   1.1  A Comparison of LANs and PABXs
   1.2  LAN Capabilities
   1.3  Planning for a LAN

 2.0 LAN TECHNOLOGY   . . . . . . . . . . . . . . . . . . . . . . . . . G066880
   2.1  Physical LAN Attachment
     2.1.1  Media Types
       2.1.1.2  Fiber Optic Cable
     2.1.2  Network Topologies
     2.1.3  Transmission Techniques
   2.2  LAN Medium Access Protocols
     2.2.1  Basic CSMA/CD Concepts
     2.2.2  Basic Token-Passing Ring Concepts
       2.2.2.1  MAC Addressing
       2.2.2.2  Early Token Release
       2.2.2.3  Token Monitoring
       2.2.2.4  Neighbor Notification
     2.2.3  Basic Token-Passing Bus Concepts
   2.3  Fiber Distributed Data Interface Concepts
       2.3.1.2  FDDI Standards
   2.4  LAN Station Management
     2.4.1  Open Systems Management
       2.4.1.2  Registration
     2.4.2  Resource Management
     2.4.3  Name Management

 3.0 LAN ARCHITECTURES AND STANDARDS  . . . . . . . . . . . . . . . . . G066879
   3.1  LAN and Communications Standards
     3.1.1  IEEE 802 and OSI
     3.1.2  OSI and SNA Models
   3.2  LAN Standards
     3.2.1  Physical Layer and MAC Sublayer
       3.2.1.1  IEEE 802.3, IS 8802-3
       3.2.1.2  IEEE 802.4, ISO 8802-4
       3.2.1.3  IEEE 802.5, ISO IS 8802-5
       3.2.1.4  Fiber Distributed Data Interface
     3.2.2  Logical Link Control Sublayer
       3.2.2.2  IEEE 802.2, ISO 8802-2
       3.2.2.3  LLC Protocol Data Unit
   3.3  LAN Standards Summary

 4.0 STRUCTURED WIRING  . . . . . . . . . . . . . . . . . . . . . . . . G066878
     4.1.1  Star-Wired Environments
     4.1.2  Other Wiring Environments
   4.2  IBM Cabling System

 5.0 IBM LOCAL AREA NETWORK SOLUTIONS   . . . . . . . . . . . . . . . . G066877
   5.1  IBM Token-Ring Network
     5.1.1  IBM Token-Ring Network Components
       5.1.1.1  Cabling Components
       5.1.1.2  IBM 8230 Controlled Access Unit
       5.1.1.3  Repeaters and Converters
       5.1.1.4  IBM 8218 Copper Repeater
       5.1.1.5  IBM 8219 Optical Fiber Repeater
       5.1.1.6  IBM 8220 Optical Fiber Converter
     5.1.2  IBM Token-Ring Network Devices
     5.1.3  IBM PC Network (Broadband) Components
     5.1.4  IBM PC Network (Broadband) Interfaces
   5.2  IBM PC Network Baseband
     5.2.1  PC Network Baseband Components
     5.2.2  PC Network Baseband Interfaces
   5.3  Ethernet/IEEE 802.3
     5.3.1  Workstations
     5.3.2  Bridges
     5.3.3  Gateways
   5.4  Industrial LAN
     5.4.1  The 8232 LAN Channel Station and Industrial LAN
     5.4.2  Migration to MAP 3.0
     5.4.3  MAP - SNA Gateway
     5.4.4  Series/1 and Industrial LAN
   5.5  TCP/IP
     5.5.1  Structure
     5.5.2  Addressing and Routing
     5.5.3  TCP/IP Applications
   5.6  IBM LAN Support Program
     5.6.1  Base Programming Interfaces
       5.6.1.1  Open IEEE 802.2 LLC Interface
       5.6.1.2  NetBIOS Interface
       5.6.1.3  LU 6.2 Interface
     5.6.2  LAN Support Program Structure
     5.6.3  OS/2 Extended Edition 1.1 LAN Support Structure
     5.6.4  OS/2 EE 1.1 LAN Support versus IBM LAN Support Program V1.10
     5.6.5  IBM LAN Support Program Version 1.2
     5.6.6  OS/2 Extended Edition 1.2 LAN Support
   5.7  3174-Peer Communications RPQ 8Q0718
     5.7.1  General description
     5.7.2  Customization and Management
     5.7.3  Hardware/Software Requirements
     5.7.4  Summary
   5.8  IBM LAN Offerings Summary

 6.0 LAN SEGMENTS INTERCONNECTION   . . . . . . . . . . . . . . . . . . G066876
   6.1  Bridges, Routers and Gateways
   6.2  Bridged LANs
     6.2.1  Bridge Configurations
   6.3  Bridge Standards
     6.3.1  Transparent Bridging
     6.3.2  Source Routing
     6.3.3  Source Routing/Transparent Bridging Inter-operability
   6.4  Bridge LAN Management Interface
   6.5  Remote Bridge
   6.6  IBM LAN Bridges
     6.6.1  IBM Token-Ring Bridges
     6.6.2  IBM Token-Ring Network Bridge Program Version 2.2
     6.6.3  IBM PC Network Bridge Program
   6.7  IBM 8209 LAN Bridge
     6.7.1  Token-Ring to Token-Ring
     6.7.2  Token-Ring to Ethernet/IEEE 802.3
     6.7.3  General Description
     6.7.4  8209 Operation
     6.7.5  Frame Conversion
     6.7.6  The Utility Program
     6.7.7  Configuration Switches
     6.7.8  Token-Ring Management Support
     6.7.9  Enhanced Ethernet Attachment Feature
     6.7.10  Summary
   6.8  IBM Bridge Products Coexistence and Migration
   6.9  Routers
     6.9.1  The IBM LAN to LAN Wide Area Network Program

 7.0 LAN GATEWAYS   . . . . . . . . . . . . . . . . . . . . . . . . . . G066875
   7.1  PC/PS2 Gateways
     7.1.1  SNA 3270
       7.1.1.2  Personal Communications/3270
     7.1.2  Asynchronous Communication PC Gateways
   7.2  Dedicated SNA Gateways
     7.2.1  SNA System/370 Host Connectivity
       7.2.1.1  9370 Processor
       7.2.1.2  37xx Communication Controllers
     7.2.2  3174 Local Gateway
     7.2.3  3174 Remote Gateways
     7.2.4  Gateway INN/BNN Connectivity
   7.3  Non-SNA Gateways
     7.3.1  8232 LAN Channel Station
     7.3.2   IBM 3172 Interconnect Controller
       7.3.2.1  IBM 3172 Model 001
       7.3.2.2  Interconnect Controller Program Version 2.0
       7.3.2.3  Interconnect Controller Program Version 2.1
     7.3.3  IBM 3172 Model 002
     7.3.4  Interconnect Controller Program Version 2.x (Statement of
          Direction)
     7.3.5  IBM 3172 Interconnect Controller Summary
   7.4  Host Gateways - Conclusion
     7.4.1  Selection Criteria
     7.4.2  Functional Comparison
     7.4.3  Gateway Positioning
   7.5  AS/400 LAN Attachment
   7.6  3174 x3R Establishment Controllers
     7.6.1  Single-link, multiple host support

 8.0 LAN SERVERS  . . . . . . . . . . . . . . . . . . . . . . . . . . . G066874
   8.1  IBM PC LAN Program V1.2
     8.1.2  IBM PC LAN Program V1.3
     8.1.3  OS/2 LAN Server Version 1.2
     8.1.4  System/36 PC LAN Support
     8.1.5  AS/400 PC LAN Support
     8.1.6  LAN PrintManager

 9.0 LAN MANAGEMENT AND RECOVERY  . . . . . . . . . . . . . . . . . . . G066873
   9.1  IBM's Total Network Management Strategy
   9.2  LAN Management and MAC Architecture
   9.3  IBM LAN Management Products Overview
     9.3.1  IBM PC 3270 Emulation LAN Management Program Version 1.0
     9.3.2  IBM LAN Manager Entry Version 1
     9.3.3  IBM LAN Manager V1.0
     9.3.4  IBM LAN Manager V2.0
     9.3.5  IBM LAN Network Manager V1
       9.3.5.2  Support for the IBM 8230 Controlled Access Unit (CAU)
       9.3.5.3  Security (Access Control)
     9.3.6  IBM LAN Network Manager Entry
     9.3.7  IBM LAN Network Manager V1.1
     9.3.8  Migration and Coexistence
   9.4  Management Capabilities of IBM SNA Gateways
     9.4.1  3174
     9.4.2  Communication Controllers
     9.4.3  9370
     9.4.4  AS/400
   9.5  IBM LAN Station Manager V1.0
     9.5.1  Name Management
     9.5.2  Resource Management
     9.5.3  Service Interface
     9.5.4  Summary
   9.6  NetView/PC
   9.7  IBM Token-Ring Network Trace and Performance Facilities
   9.8  IBM LAN Management Products Summary

 10.0 LAN POSITIONING   . . . . . . . . . . . . . . . . . . . . . . . . G066872
   10.1  IEEE 802.3, ISO IS 8802-3
   10.2  IEEE 802.4, ISO IS 8802-4
   10.3  IEEE 802.5, ISO IS 8802-5
   10.4  ANSI X3T9.5 ISO 9314 FDDI
   10.5  LAN Interfaces

 LIST OF ABBREVIATIONS

 INDEX

 END-OF-TOC

 INTERNATIONAL TECHNICAL SUPPORT CENTER
 LOCAL AREA NETWORK LIBRARY
 LOCAL AREA NETWORKS
 CONCEPTS AND PRODUCTS

 Document Number GG24-3178-2

 September 1990

 International Technical Support Center
 Raleigh, North Carolina

 +--- TAKE NOTE --------------------------------------------------------------+
 ]                                                                            ]
 ] Before using this information and the product it supports, be sure to read ]
 ] the general information under "Special Notices."                           ]
 +----------------------------------------------------------------------------+
 THIRD EDITION (SEPTEMBER 1990)

 This edition applies to various IBM products available for current LAN
 architectures.
 Order publications through your IBM representative or the IBM branch office
 serving your locality.  Publications are not stocked at the address given
 below.
 A form for reader's comments appears at the back of this publication.  If the
 form has been removed, address your comments to:
 IBM Corporation, International Technical Support Center
 Dept. 985, Building 657
 P. O. Box 12195
 Research Triangle Park, NC 27709 USA

 (c) Copyright International Business Machines Corporation 1990

 Special Notices
 This publication is intended to provide an understanding of LANs and IBM LAN
 solutions for planning and support purposes.  It contains descriptions of LAN
 architectures, bridges, and LAN network management.  The information in this
 publication is not intended as the specification of the programming interfaces
 that are provided by the IBM Token-Ring Network for use by customers in
 writing programs that request or receive its services.  See the PUBLICATIONS
 section of the IBM PROGRAMMING ANNOUNCEMENT for the IBM Token-Ring Network.
 References in this publication to IBM products, programs or services do not
 imply that IBM intends to make these available in all countries in which IBM
 operates.  Any reference to an IBM product, program, or service is not
 intended to state or imply that only IBM's product, program, or service may be
 used.  Any functionally equivalent program that does not infringe any of IBM's
 intellectual property rights may be used instead of the IBM product, program
 or service.
 Information in this book was developed in conjunction with use of the
 equipment specified, and is limited in application to those specific hardware
 and software products and levels.
 IBM may have patents or pending patent applications covering subject matter in
 this document.  The furnishing of this document does not give you any license
 to these patents.  You can send license inquiries, in writing, to the IBM
 Director of Commercial Relations, IBM Corporation, Purchase, NY 10577.
 The information contained in this document has not been submitted to any
 formal IBM test and is distributed AS IS.  The use of this information or the
 implementation of any of these techniques is a customer responsibility and
 depends on the customer's ability to evaluate and integrate them into the
 customer's operational environment.  While each item may have been reviewed by
 IBM for accuracy in a specific situation, there is no guarantee that the same
 or similar results will be obtained elsewhere.  Customers attempting to adapt
 these techniques to their own environments do so at their own risk.
 Reference to PTF numbers that have not been released through the normal
 distribution process does not imply general availability.  The purpose of
 including these reference numbers is to alert IBM customers to specific
 information relative to the implementation of the PTF when it becomes
 available to each customer according to the normal IBM PTF distribution
 process.
 The following products and features referenced in this publication are
 trademarks of the International Business Machines Corporation:
     Application System/400, AS/400
     ES/3090, 3090, ES/9370, System/360, System/370
     MVS/SP, MVS/XA
     NCP
     ACF/VTAM
     NetView, NetView/PC
     Operating System/2, OS/2
     Operating System/400, OS/400
     Personal Computer XT, PC/XT
     Micro Channel
     System/36, System/38
     IBM
     SAA
     Presentation Manager
     Personal Computer AT, AT
     Personal System/2, PS/2
     PROFS
     ProPrinter
     RT Personal Computer, RT PC, RT
 The following terms are trademarks of other companies.
     Ethernet is a trademark of Xerox Corporation
     Unix is a trademark of AT & T.

 Abstract


 Document ID G066876
 TITLE: GG24-3178
        IN GREATER DETAIL IN "6.0 LAN SEGMENTS INTERCONNECTION."


 in greater detail in "6.0 LAN Segments Interconnection."
 Using a LAN segment as an elementary building block permits design of
 interconnected multi-segment local area network with a wide range of possible
 topologies. Again, each of these topologies has its advantages and
 disadvantages. They are discussed in "6.2.1 Bridge Configurations."
 Figure 7 under heading "2.1.2.1.4  Ring Topologies" introduces various
 concepts related to multi-segment networks.
 +------------------------------------------------------------------------------
 ]
 ]
 ]            *---*   *-----------*           *-----------*           ]
 ]            ]   ]---]           ]           ]           ]           ]   *---*
 ]            *---*   ]           ]   *---*   ]           ] Bridge or ]---]   ]
 ]     --*            ]           ]---]   ]---]           ]  Router   ]   *---*
 ]       ]            ]    LAN    ]   *---*   ]    LAN    ]   *---*   ]   LAN
 ]     W ]            ]  segment  ]   Bridge  ]  segment  ]---]   ]---] segment
 ]       ]   Gateway  ]     A     ]     1     ]     B     ]   *---*   ]    C
 ]     A ]--/ *---*   ]           ]   *---*   ]           ]           ]   *---*
 ]       ] /--]   ]---]           ]---]   ]---]           ]           ]---]   ]
 ]     N ]    *---*   ]           ]   *---*   ]           ]   *---*   ]   *---*
 ]       ]            ]           ]   Bridge  ]           ]---]   ]   ]
 ]     --*            *-----------*     2     *-----------*   *---*
 ]
 ]            <--------------- Multi-segment Local Area Network -------------->
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 7. Multi-Segment LAN Example

 2.1.3  Transmission Techniques

 2.1.3.1.1  Baseband Transmission:  Baseband transmission involves putting a
 signal directly on the transmission medium without modulating a carrier
 signal.  At any point in time, the information occupies the entire bandwidth
 available on the medium.  Sharing of the medium can be achieved by allocating
 time slices to different applications.  This technique is known as TIME
 DIVISION MULTIPLEXING (TDM).  It is a simple technique and together with the
 fact that no modulating/demodulating devices are required, Baseband is a
 relatively inexpensive transmission technology.
 Baseband-transmitted signals must be regenerated periodically when
 transmitting signals over long distances or through multiple connection
 points.  This is due to cable attenuation (losses in signal strength caused by
 the physical and electrical characteristics of the medium) and losses
 associated with connectors and/or attachments.
 The IBM Token-Ring Network uses baseband transmission, operating at a speed of
 4 or 16 Megabits per second (4 Mbps or 16 Mbps), and the IBM PC Network
 Baseband uses baseband transmission at 2 Mbps.

 2.1.3.1.2  Broadband Transmission:  Broadband transmission involves use of
 techniques to allow generation of signals over multiple channels.  In most
 cases, broadband transmission is based upon use of radio frequency modems in
 the same way as radio and television signals are transmitted.  Resource
 sharing is accomplished by dividing the medium into logical channels using
 FREQUENCY DIVISION MULTIPLEXING.  Any individual channel could use time
 division multiplexing to provide further sharing.
 Since broadband transmission uses multi-channel "CATV-like" technology, it is
 ideally suited to transmit voice and video. Hence, the broadband approach
 offers the greatest potential to support voice, video, and data on a single
 cabling system today.  For this reason broadband transmission is quite popular
 in manufacturing plants.
 Transmission of video signals requires only a single channel, because it is
 transmit only.  Data communication involves both transmit and receive.
 Therefore two channels are required. In order to minimize interference between
 the transmit and receive channels, significantly separated frequency ranges
 should be used. Within a transmit/receive channel pair, this characteristic is
 indicated as the frequency offset, with the forward (higher) frequency range
 separated from the return (lower) frequency range by a set of frequencies
 referred to as the guard band.  Within each range a sub-range of 6 Mhz defines
 one channel of a channel pair, where the pair is composed of a return channel
 below the offset, and a forward channel which corresponds to the lower channel
 frequency plus the offset.  See Figure 8 under heading "2.1.3.1.2  Broadband
 Transmission".
 +------------------------------------------------------------------------------
 ]
 ]
 ]           ] ]1]1]2]2]3]4]4] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]Frequency  ]5]1]7]3]9]5]1]7] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]MHz        ].].].].].].].].] ] ] ] ] ] ] ] ]1]1]1]1]1]1]1]1]1]1]1]1]1]1]1]1]1]
 ]           ]7]7]7]7]7]7]7]7]5]6]6]7]7]8]9]9]0]0]1]2]2]3]3]4]5]5]6]6]7]8]8]9]9]
 ]           ]5]5]5]5]5]5]5]5]4]0]6]2]8]4]0]6]2]8]4]0]6]2]8]4]0]6]2]8]4]0]6]2]8]
 ]------------------------------------------------------------------------------
 ]           ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]Standard   ]T]T]T]T]T]T]T] ]2]3]4]4]5]6]F]F]F] ] ]A]B]C]D]E]F]G]H]I]7]8]9]1]1]
 ]CATV       ]7]8]9]1]1]1]1] ] ] ] ]A] ] ]M]M]M] ] ] ] ] ] ] ] ] ] ] ] ] ] ]0]1]
 ]Channels   ] ] ] ]0]1]2]3] ] ] ] ] ] ] ]1]2]3] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]           ]------------------------------------------------------------------
 ]Frequency  ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]Bands      ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ] Sub-Split ]R]R]R]R]*]*]*]*]*]F]F]F]F] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]  (4 Pairs)] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ] Mid-Split ]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]*]*]*]*]*]*]*]*]*]*]F]F]F]F]F]F]
 ] (17 Pairs)] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ] High-Split]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]R]*]*]*]
 ] (30 Pairs)] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]           ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]           ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ]
 ]           -------------------------------------------------------------------
 ]
 ]R = Return Band
 ]F = Forward Band
 ]* = Guard Band
 ]
 +------------------------------------------------------------------------------
 Figure 8. Broadband Transmission Frequency Bands and Offsets
 With respect to the number of channels and their associated guard bands,
 industry standard channel pairs have been defined with specific frequency
 offsets between the channels within a pair.  Mid-split broadband transmission
 refers to 17 channel pairs and a 116 to 168 MHz guard band (168 Mhz offset).
 High-split refers to 30 channel pairs and a guard band of 186 to 222 MHz (122
 Mhz offset).
 Due to the high cost involved with the multi-channel capability, a modulated
 transmission technique on a single channel pair medium has been defined and is
 referred to as carrierband transmission.
 The IBM PC Network (Broadband) uses broadband transmission at 2 Mbps,
 supporting one of the following channel pair frequency options:
 o   Return Band frequency 50.75 Mhz, Forward Band 219 Mhz
 o   Return Band frequency 56.75 Mhz, Forward Band 249 Mhz
 o   Return Band frequency 62.75 Mhz, Forward Band 255 Mhz.

 2.2  LAN Medium Access Protocols

 2.2.1  Basic CSMA/CD Concepts
 The access to the medium on a LAN controlled by a CARRIER SENSE MULTIPLE
 ACCESS WITH COLLISION DETECTION (CSMA/CD) access protocol is based on
 contention between competing stations. The access is said to be PROBABILISTIC
 rather than deterministic.  CSMA/CD is appropriate for use only with bus or
 tree topologies because of the collision detection mechanism. In order to
 detect signal collisions, all stations on the LAN must be able to sense the
 presence of a carrier on the medium.  This does not happen with a ring
 topology in which a signal is passed serially from one station to the next.
 Three main topology/transmission technique combinations are used for CSMA/CD
 LANs: baseband bus (the most popular), baseband bus with star-wired device
 controllers, and broadband tree.  In each case, station attachment is passive.
 The signal is neither regenerated nor amplified by the LAN stations. This
 limits the maximum non-repeated station-to-station distance (typically 500
 meters on a baseband bus).  In addition, distance between attaching stations
 must be a minimum of 2.5 meters to minimize the effect of signal reflections
 in the taps (that is to avoid reflections adding up in phase).
 Before transmitting data, a station first listens to the medium to find out
 whether the medium is idle or whether another station is already transmitting
 data.  If the network is quiet, the station may start its own transmission.
 The protocol provides multiple access, that is the access mechanism applies to
 all LAN stations concurrently.  Therefore it is possible that two stations
 could start to transmit at about the same time.  Due to propagation delays
 (media delay, delays at taps and/or repeaters), a station may determine that
 the medium is idle and start to transmit, while at the other end of the bus a
 station has already started transmission.  Two (or more) stations concurrently
 broadcasting data on a common medium inevitably cause a collision.  The
 collision is detected as the station listens to the medium while it is
 transmitting (COLLISION DETECTION).  This process is called LISTEN WHILE TALK.
 Both stations stop transmission and try again later.
 The critical part of the CSMA/CD protocol is the recovery process after a
 collision has occurred.  It is this aspect of the CSMA/CD medium access
 protocol that causes response time and throughput to be probabilistic.
 In general, collision recovery proceeds as follows:

 1.  As soon as a station detects a collision, it stops transmitting data
     immediately and sends a jamming signal.  Since the first condition to make
     any recovery possible is to stop all additional traffic, the jamming
     signal informs all active stations about the collision.
 2.  After being informed about the collision, each station wishing to transmit
     data must wait a random amount of time before initiating the whole process
     again, starting with carrier sensing etc.
 Three CSMA/CD variations provide increasing degrees of sophistication and
 optimization:
 o   NON-PERSISTENT RULES
     1.  If the medium is idle, transmit.
     2.  If the medium is busy, wait a random amount of time and repeat step 1.

     This method is very simple but inefficient, especially with high
     utilization of the medium because the opportunity to transmit during a
     brief idle period may be missed.
 o   1-PERSISTENT RULES
     1.  If the medium is idle, transmit.
     2.  If the medium is busy, continue to listen until the medium is idle,
         then transmit immediately.
     3.  If there is a collision,  wait a random amount of time and repeat step
         1.

     If two or more stations are waiting to transmit, a collision will always
     occur when the medium becomes available.  However, since each station will
     wait a random amount of time after a collision and before retransmitting,
     things will sort themselves out from there.  However the delays created by
     the non-persistent rules for normal busy media will be avoided.

     Within existing CSMA/CD implementations, this method is the most popular.
 o   P-PERSISTENT RULES

     The p-persistent protocol tries to eliminate the collision that happens
     with the 1-persistent protocol when the medium is busy and more than one
     station is waiting to transmit. The rules are:
     1.  If the medium is idle, transmit with a probability of p.  Hence there
         is a probability of q=(1-p) that the station will wait for the next
         time slot.
     2.  If the medium is busy, continue to listen until the medium is idle,
         then repeat step 1.
     3.  If there is a collision, wait one time slot and repeat step 1.

     The main problem with this approach is choosing a value for p.  P must be
     kept low to avoid instability, but this increases the wait probability
     (q).  This approach tends to be unstable with highly utilized media.

 The 1-persistent protocol wastes less time after a collision than the
 non-persistent protocol.  The random backoff after a collision reduces the
 chances of two stations contending for the medium again.  Under high traffic
 conditions, the 1-persistent rules are more like to run into collision and
 thus create instability.  However when p=1 then q=0, and therefore there is no
 wait probability.  Thus under normal or low traffic conditions the
 1-persistent protocol can provide better throughput.
 In conclusion, CSMA/CD or contention protocols in general perform best when
 medium utilization is low.  High utilization increases the number of
 collisions and collision retransmissions, further adding to the utilization.
 Sensitivity to increased traffic load is one of the major drawbacks of CSMA/CD
 protocols.

 2.2.1.1.1  Frame Format:  Figure 9 under heading "2.2.1.1.1  Frame Format"
 shows the frame format used for data transmission on a CSMA/CD LAN according
 to the international standard specification issued by the IEEE 802.3.  See
 "3.0 LAN Architectures and Standards" .  Note that this format is slightly
 different from that used by "Ethernet" adapters.
 +------------------------------------------------------------------------------
 ]
 ]                                                                   Physical
 ]      ]<------------- Physical Header -------------->]          ]<-Trailer->]
 ]      ]             ]<------------------ FCS Protection ------------------->]
 ]      *---------------------------------------------------------------------*
 ]      ]Preamble] SD ] Destination ]Source      ] LF ]Information] PAD ] FCS ]
 ]      ]        ]    ] Address (DA)]Address (SA)]    ]           ]     ]     ]
 ]      *---------------------------------------------------------------------*
 ]       7        1 ] ]2,6          ]2,6          2 ]  0-n         0-m]  4 ]
 ]       ] Starting * ]             ]               Length         Padding ]
 ]       ] Delimiter  ]             ]               Field                  ]
 ]       ] B'10101011']             *-----*                            Frame
 ]       ]            ]                   ]                            Check
 ]       Field        ]                   ]                            Sequence
 ]       Length       *-------------------*  I/G = Individual /Group address
 ]       in Bytes     ]I/G]15 address bits]        B'0'        B'1'
 ]                    *-------------------*  U/L = Universally/Locally admin.
 ]                    <- 16 bit address -->        B'0'        B'1'
 ]
 ]                    *------------------------------------------------------*
 ]                    ]I/G]U/L]46 address bits                               ]
 ]                    *------------------------------------------------------*
 ]                    <------------------ 48 bit address field -------------->
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 9. IEEE 802.3 MAC Frame Format
 o   Preamble- 7 padding bytes, allow the physical layer signalling (PLS)
     circuitry to synchronize with the receive frame timing circuitry.
 o   SA, DA - 16-bit or 48-bit medium access control (MAC) address fields
     according to the IEEE and ISO standards. A vendor is free to choose either
     of them but all stations on a given LAN must use the same addressing
     structure. Most current LAN implementations use 48-bit addressing, but
     some early LANs use 16-bit address fields.
 o   LF - length field, indicating the actual length of the information field.
 o   Information field - may contain a LLC protocol data unit (LPDU).
 o   Padding - may contain padding characters if the minimum frame length
     requirement is not met (512 bits).
 o   FCS - the result (32 bits) of a cyclic redundancy check algorithm
     (specific polynomial executed against the contents of DA, SA, LF,
     information and pad fields).
 o   An invalid frame is not passed to the next higher protocol layer (the LLC
     sublayer), but is discarded by MAC level processing for any of the
     following reasons:
     -   The frame does not contain an integral number of bytes.
     -   The content of frame length field is inconsistent with the actual
         frame length.
     -   The FCS value calculated upon by the destination station does not
         match the FCS value contained within the frame.

 2.2.1.1.2  Additional CSMA/CD Considerations
 o   Cabling considerations

     With CSMA/CD baseband bus topology, 50 ohm impedance coax wire is
     recommended to reduce the capacitance caused by the taps.  Almost all
     other communications cables use an impedance of at least 75 ohms.
     Frequently the long term implications of a particular cable type may be
     overlooked during initial design and installation.  If a CSMA/CD LAN using
     50 ohm cable over time provides insufficient capacity for the required
     data traffic, rewiring will usually be required and may turn out to be a
     very costly operation.
 o   Probability of collisions

     The probability of a collision occurring is proportional to the number of
     stations, the number of transmissions per time interval, the length of the
     LAN, the LAN utilization and the size and number of the collision windows
     involved. A COLLISION WINDOW is the time during which a collision may
     occur. Its maximum value is the time required by a signal to travel
     between the two outmost stations on a CSMA/CD LAN. On a 10 Mbps CSMA/CD
     baseband LAN the collision window size equals the one-way propagation
     delay (sum of all transmission delays) between the contending stations.
     While the size of collision windows may be decreased by reducing the frame
     size used by adapters, it is not recommended since it will also increase
     the number of windows and the overhead caused by frame headers and
     trailers.

     Baseband collision detection is usually accomplished by measuring the
     signal strength on the bus. Therefore the signal between the two outmost
     stations must be considerably stronger than normal noise levels.
     Consequently, on a CSMA/CD baseband LAN, signal repeaters are generally
     required every 500 meters. This has a positive consequence for the
     recovery of relatively large frames. On the average, only about 512 bits
     would have been transmitted when the collision is detected.  This stops
     the frame transmission and initiates the recovery process.

     SLOT TIME is the minimum transmission time required by a station to ensure
     it can hear all possible collisions and is equal to twice the maximum
     collision window size. This implies a minimum frame size on a 10 Mbps
     CSMA/CD baseband LAN of 512 bits.  The frame header and trailer parts
     require 208 bits, which leaves a 304-bit data field in a minimum length
     frame.   In shorter frames such as most control frames and short messages,
     padding characters must be appended to the data field (refer to the frame
     format).  An increase in transmission speed increases the minimum frame
     size.

     Early CSMA/CD LANs had relatively few attachments such as processors and
     terminal servers (controllers which served multiple fixed function
     devices).  With the advent of the intelligent programmable workstation,
     the desire to attach such devices directly to the LAN may significantly
     increase the number of attachments and alter traffic characteristics.  Any
     associated increase in collision probability should be considered in
     designing a LAN which will use intelligent workstations.
 o   Collision resolution

     As mentioned before, the first station to detect a collision immediately
     transmits a JAMMING SIGNAL to notify all listening stations that a
     collision has occurred.  In response to this signal, each station enters a
     BINARY EXPONENTIAL BACKOFF ALGORITHM, causing each station to wait for a
     random amount of time before attempting to transmit again.  If a station's
     subsequent attempt results in another collision, its backoff delay is
     doubled.  This process may be repeated up to 16 times, after which the
     station, if still unsuccessful, reports a transmission error. There is no
     guaranteed delivery at the CSMA/CD MAC level.  If traffic levels are high,
     the more retries a station requires, the worse its chances to succeed may
     be when attempting again.
 o   Basic performance

     CSMA/CD protocols optimize throughput and response time under conditions
     of relatively low (less than 40%) bandwidth utilization.

     Test measurements indicate that typical user data frames contain about
     1000 bits.  Using this frame size to simulate the performance of a 10 Mbps
     CSMA/CD LAN with 100 active LAN devices results in a maximum throughput of
     about 3.6 Mbps because of the sensitivity of the protocol to load.

     Increasing the transmission speed on a CSMA/CD LAN does not significantly
     improve throughput since the minimum frame length increases
     proportionally. It may also imply a requirement for more expensive media
     and additional repeaters since signal attenuation is proportional to the
     square of the transmission speed.
 o   LAN growth

     In response to growth requirements, one might attempt to increase the
     maximum allowable distance.  However, this also implies increased slot
     time, minimum frame length and larger collision windows for any given
     load.

     When such architectural constraints create a problem, they may be
     addressed by bridging separate CSMA/CD LANs together to form an
     interconnected CSMA/CD LAN as discussed earlier.
 o   CSMA/CD interconnection considerations

     When attempting to project future load growth, it may be risky to
     underestimate capacity requirements. Recent explosive growth in
     communications bandwidth requirements is likely to continue in LAN
     environments.  Such applications as image and file servers will quickly
     use the spare capacity now available.

     More detailed analysis of future load growth will show the increasing
     importance of LAN INTERCONNECTION and higher capacity BACKBONE LANS.

     A potential problem for any LAN bridge is FRAME LOSS.  Generally, frame
     loss can occur because of high loads on the LAN or at the bridge level
     (for example, a bridge running out of queuing capacity).

     Excessive frame loss in a CSMA/CD bridge (resulting from collisions) is a
     much more significant problem.  CSMA/CD LANs have no priority mechanism at
     the MAC level, and bridge adapters (for example, to backbone LAN segments)
     by nature tend to experience the highest loads, and will be the most
     likely ones to be involved in collision recovery.  A bridge may also be
     subject to peak load situations on both sides of the bridge, further
     decreasing the probability of successful frame transmission across the
     bridge.

     The probability of successful end-to-end data transmission is obtained by
     multiplying the probabilities associated with each bridge in the path
     together.  This may lead to unacceptable situations if the load increases
     in one or more LAN segments.  Unfortunately backbone LANs, only accessible
     via bridges, may be the most likely ones to experience high traffic loads.
     Thus care should be taken during design to ensure that such backbones have
     relatively few attachments (that is, bridges).

     A backbone LAN sometimes needs to offer a transmission speed exceeding the
     speed of the lower level LANs that are interconnected.  As explained
     before, 10 Mbps is a practical limit for CSMA/CD LANs.  Backbone LANs
     based upon other medium access protocols may offer a more attractive
     solution, despite the need for installation of different cabling for the
     backbone.

     A common routing technique used in CSMA/CD bridges is based on tables.
     Tables are dynamically built at the bridge level containing station
     addresses identified on both sides of the bridge. These tables may become
     quite large in an expanding LAN environment, and may consume considerable
     buffer space and processing capacity for table lookup and maintenance.
     This must be considered when configuring such bridges.  In CSMA/CD LANs
     parallel active bridges to support heavier traffic would cause duplicate
     frames and collisions and thus are prohibited.  One bridge routing
     algorithm, called spanning tree, does not allow duplicate frames and
     provides mechanisms to ensure that parallel bridges or routes are not
     concurrently active.  Bridge routing techniques are discussed in "6.3
     Bridge Standards."

 2.2.2  Basic Token-Passing Ring Concepts
 A token-ring network consists of the ATTACHING MEDIUM and RING STATIONS
 (devices able to attach to the ring and to use the link access protocols).
 A token-ring network uses one of several twisted pair media specifications,
 each having its own price/performance ratio, and all suitable to carry most
 other data communications signals.  A token-ring network may also use optical
 fiber media.
 A single segment token-ring LAN installation is illustrated in Figure 10 under
 heading "2.2.2  Basic Token-Passing Ring Concepts".

 +------------------------------------------------------------------------------
 ]
 ]     A.) Normal operation on Primary Path
 ]     --------------------------------
 ]           *--* *--*                              *--*      *--*
 ]           ]S9] ]S8]                              ]S7]      ]S6]
 ]           **** ****               Primary Path   ****      ****
 ]     *-<--* ]]   ]]            *--<----<----<---<* ]]        ]]      *----*
 ]     ]   *]-]]---]]------------]*               *]-]]--------]]------]*   ]
 ]     ]   ]*<**-<-**-<----<---<-*]               ]*<**-<---<--**-<---<*]   A
 ]     ] ..]......................]...............].....................].. ]
 ]     ] . ]RO       PWC 4      RI]  Backup Path  ]RO       PWC 3     RI] . ]
 ]     ] . *----------------------*    (Idle)     *---------------------* . ]
 ]     ] .                                                                . ]
 ]     ] . *----------------------*               *---------------------* . ]
 ]     ] . ]RI       PWC 1      RO]               ]RI       PWC 2     RO] . ]
 ]     ] ..]......................]...............].....................].. ]
 ]     ]   ]*-**-->--->---->--->-*]               ]*-**->---->---->-**-*]   ]
 ]     ]   *]-]]--------**-------]*               *]-]]---**--------]]-]*   ]
 ]     *-->-* ]]        ]]       *--->---->---->---* ]]   ]]        ]] *----*
 ]           ****      ****                         **** ****      ****
 ]           ]S1]      ]S2]                         ]S3] ]S4]      ]S5]
 ]           *--*      *--*                         *--* *--*      *--*
 ]
 ]
 ]     B.) Backup operation on Primary and Backup Path
 ]     -------------------------------------------
 ]           *--* *--*                              *--*      *--*
 ]           ]S9] ]S8]                              ]S7]      ]S6]
 ]           **** ****               Primary Path   ****      ****
 ]     *--<--*]]   ]]           *--<----<----<----<-*]]        ]]     *--<--*
 ]     ] *>-*]]]   ]]           ]*-->---->---->---->]]]        ]]     ]*>-* ]
 ]     ] ] *]]]]---]]-----------]]*  Backup Path  -]]**--------**-----]]- ] ]
 ]     ] ] ]]***-<-**-<----<----*]]               ]]*--------<--------*]] ] ]
 ]     ] ] ]*->---->---->--->----*]               ]*->---->---->---->--*] ] ]
 ]     ] ] ]RO       PWC 4      RI]               ]RO       PWC 3     RI] ] ]
 ]     ] ] *----------------------*               *---------------------* ] ]
 ]     ] ]                                                                ] ]
 ]     ] ] *----------------------*               *---------------------* ] ]
 ]     ] ] ]RI       PWC 1      RO]               ]RI       PWC 2     RO] ] ]
 ]     ] ] ]*---<----<---<----<--*] ............. ]*--<------<------<--*] ] ]
 ]     ] ] ]]***->---->--->---->-*] ------------- ]*-**->---->--->--***]] ] ]
 ]     ] ] *]]]]--------**--------*  Broken Cable *--]]---**--------]]]]* ] ]
 ]     ] *<-*]]]        ]]             Segment       ]]   ]]        ]]]*-<* ]
 ]     *->---*]]        ]]            (removed)      ]]   ]]        ]]*--->-*
 ]           ****      ****                         **** ****      ****
 ]           ]S1]      ]S2]                         ]S3] ]S4]      ]S5]
 ]           *--*      *--*                         *--* *--*      *--*
 ]
 ]
 ]            RI = Ring In           PWC = Passive Wiring Concentrator
 ]            RO = Ring Out          Sn  = LAN Station
 ]
 +------------------------------------------------------------------------------
 Figure 10. Token-Passing Ring Data Paths
 This figure shows four PASSIVE WIRING CONCENTRATORS (PWC) and 9 physically
 attached nodes.  The power from the attached nodes when transmitted to the
 concentrator activates relays in the concentrator to allow the station to send
 signals across the LAN to other stations.  In Part A of Figure 10 under
 heading "2.2.2  Basic Token-Passing Ring Concepts" two adapters (nodes S2 and
 S4) have not powered their respective PWC relays and therefore their lobe
 wires are internally bypassed.  In Part B of Figure 10 under heading "2.2.2
 Basic Token-Passing Ring Concepts" four adapters (nodes S2, S4, S6 and S7) are
 not actively inserted into the ring (their lobe wires are internally bypassed)
 and the primary path is wrapped to the backup path in PWCs 1 and 2.
 When a cable segment between PWCs fails, manual removal from the appropriate
 ring-in and ring-out connectors causes automatic wrapping of the primary path
 to the backup path.  How such a permanent wire fault is reported for LAN
 management is explained in the discussion of beaconing later on in this
 section.  Recovery from the same error is automatic when using the IBM 8230
 Controlled Access Unit, which is an Active, or powered, Wiring Concentrator
 (see "5.1.1.2 IBM 8230 Controlled Access Unit")
 A ring station transfers data to the ring, in a data transmission unit called
 a FRAME. Frames are sent sequentially from one station to the next station
 physically active on the ring.  This station is called the DOWNSTREAM
 NEIGHBOR.   Each ring station repeats the frame.  While doing so it performs
 error checking on the bit stream and it will copy the data if its own address,
 either its MAC or any of its Functional Addresses, are identified as a
 destination station in the frame.  Upon return of the frame to the originating
 station, the latter will remove the data from the ring.
 In a token-passing protocol, a ring station can only transfer data to the ring
 while it is holding a TOKEN.  The token is a specific bit sequence (24 bits)
 circulating around the ring at a rated speed (4 Mbps or 16 Mbps in current
 implementations, 100 Mbps according to the Fiber Distributed Data Interface
 specification; see "2.3 Fiber Distributed Data Interface Concepts").  Because
 of the high transmission speed with respect to the total ring length, a short
 ring might contain only a few bits at any point in time.   Only one token may
 exist on a ring segment at any given point in time.  Therefore, a delay
 equivalent to the time for a token to circulate the ring is required to ensure
 that no overrun occurs which would result in a station receiving a token that
 it is transmitting and thinking that a second token exists on the ring.  For a
 24-bit token this means a minimum 24-bit delay. In addition to this delay an
 additional elastic buffer is introduced to support the token protocols and
 speed.
 In order to establish communication between any two ring stations, ADDRESSING
 mechanisms are needed. At the same time the integrity of the transmitted
 frames between ring stations must be preserved.  Therefore data checking
 capabilities are required at the MEDIUM ACCESS CONTROL level of a ring
 station.

 2.2.2.1  MAC Addressing
 Any ring station is identified by a unique INDIVIDUAL ADDRESS.  This address
 can be UNIVERSALLY ADMINISTERED, assigned by the IEEE organization (see "3.0
 LAN Architectures and Standards").  Because it is set in read-only memory
 (ROM) on a token-ring adapter card, the universally administered address is
 also called a BURNED-IN ADDRESS.
 Some manufacturers have been assigned universal addresses that contain an
 organizationally unique identifier. For instance, IBM has an identifier of
 x'10005A'. All IBM token-ring cards that use IBM token-ring chip sets, have
 the first 6 digits of their address begin with those characters. Other
 identifiers are x'000143' for IEEE 802, and x'1000D4' for DEC.
 IEEE universal addresses, whether for token-ring or 802.3 stations are all
 allocated out of the same common pool, but uniqueness is guaranteed.
 A ring station's individual address can also be LOCALLY ADMINISTERED, that is
 set at adapter-open time and typically defined by a network administrator.
 A number of destination ring stations can be identified by a GROUP MAC
 ADDRESS.  Some standard group addresses have been defined. These are listed in
 Figure 11 under heading "2.2.2.1  MAC Addressing".
 +------------------------------------------------------------------------------
 ]
 ]
 ]          *--------------------------------------------------------*
 ]          ] Bridge                             ] X'8001 4300 0000' ]
 ]          ]------------------------------------+-------------------]
 ]          ] Bridge management                  ] X'8001 4300 0008' ]
 ]          ]------------------------------------+-------------------]
 ]          ] Load Server                        ] X'8001 4300 0088' ]
 ]          ]------------------------------------+-------------------]
 ]          ] Loadable device                    ] X'8001 4300 0048' ]
 ]          ]------------------------------------+-------------------]
 ]          ] ISO 10589 level-1 Intermediate Stns] X'8001 4300 0028' ]
 ]          ]------------------------------------+-------------------]
 ]          ] ISO 10589 level-2 Intermediate Stns] X'8001 4300 00A8' ]
 ]          ]------------------------------------+-------------------]
 ]          ] FDDI RMT Directed Beacon           ] X'8001 4300 8000' ]
 ]          ]------------------------------------+-------------------]
 ]          ] FDDI status report frame           ] X'8001 4300 8008' ]
 ]          ]------------------------------------+-------------------]
 ]          ] OSI Network Layer End-stations     ] X'9000 D400 00A0' ]
 ]          ]------------------------------------+-------------------]
 ]          ] OSI NL Intermediate stations       ] X'9000 D400 0020' ]
 ]          *--------------------------------------------------------*
 +------------------------------------------------------------------------------
 Figure 11. Standardized Group Addresses
 A token-ring LAN also provides a special case of a locally administered group
 address called FUNCTIONAL ADDRESSES.  Each (bit-significant) functional
 address represents a well-identified server function within the access
 protocol.  Of 31 possible functional addresses, 14 have been defined while the
 remaining ones are reserved for future use or may be user-defined.  They are
 listed in Figure 12 under heading "2.2.2.1  MAC Addressing".
 +------------------------------------------------------------------------------
 ]
 ]          *-------------------------------------------------*
 ]          ] Active Monitor              ] X'C000 0000 0001' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Ring Parameter Server       ] X'C000 0000 0002' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Network Server Heartbeat    ] X'C000 0000 0004' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Ring Error Monitor          ] X'C000 0000 0008' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Configuration Report Server ] X'C000 0000 0010' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Synchronous Bandwidth  Mgr. ] X'C000 0000 0020' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Locate - Directory Server   ] X'C000 0000 0040' ]
 ]          ]-----------------------------+-------------------]
 ]          ] NETBIOS                     ] X'C000 0000 0080' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Bridge                      ] X'C000 0000 0100' ]
 ]          ]-----------------------------+-------------------]
 ]          ] IMPL Server                 ] X'C000 0000 0200' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Ring Authorization Server   ] X'C000 0000 0400' ]
 ]          ]-----------------------------+-------------------]
 ]          ] LAN Gateway                 ] X'C000 0000 0800' ]
 ]          ]-----------------------------+-------------------]
 ]          ] Ring Wiring Concentrator    ] X'C000 0000 1000' ]
 ]          ]-----------------------------+-------------------]
 ]          ] LAN Manager                 ] X'C000 0000 2000' ]
 ]          ]-----------------------------+-------------------]
 ]          ]                             ] X'C000 0000 8000' ]
 ]          ] User-defined                ]      through      ]
 ]          ]                             ] X'C000 4000 0000' ]
 ]          *-------------------------------------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 12. IEEE and IBM Functional Addresses
 The most relevant protocol server functions will be described in greater
 detail in the bridge and LAN management sections (see "6.6 IBM LAN Bridges"
 and "9.2 LAN Management and MAC Architecture").
 In addition two special destination address values have been defined.  The
 ALL-STATIONS BROADCAST group address X'FFFFFFFFFFFF' identifies all ring
 stations as destination stations.  A frame carrying the individual NULL
 ADDRESS X'000000000000' as its destination MAC address is not addressed to any
 ring station, therefore it can only be sent but not received.
 IEEE allows vendors to implement either 16-bit or 48-bit MAC addresses. The
 actual address field formats are shown in the picture Figure 13 under heading
 "2.2.2.1  MAC Addressing".
 +------------------------------------------------------------------------------
 ]
 ]
 ]          *------------------------------------------------------*
 ]          ]I/G]U/L]46 address bits                               ]
 ]          *------------------------------------------------------*
 ]          <------------------ 48 bit address field -------------->
 ]
 ]          *-------------------*  I/G = Individual /Group address
 ]          ]I/G]15 address bits]        B'0'        B'1'
 ]          *-------------------*  U/L = Universally/Locally administered
 ]          <- 16 bit address -->        B'0'        B'1'
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 13. IEEE LANs - MAC Address Format
 For the IBM LAN implementations, 48-bit addressing has been selected.  The
 implementation format (8 under heading "2.2.2.1  MAC Addressing") is shown in
 Figure 14 under heading "2.2.2.1  MAC Addressing".

 ---Footnote---
 (8) The universal/local address field (Byte 0, Bit 1) in a source address is
 used to indicate the presence of routing information; see "6.6 IBM LAN Bridges.
 --------------

 +------------------------------------------------------------------------------
 ]
 ]
 ]           0          1        2         3        4        5
 ]          *--------------------------------------------------------*
 ]          ]I]U]      ]        ]F]       ]        ]        ]        ]
 ]          ]/]/]<-- reserved ->]A]       ]        ]        ]        ]
 ]          ]G]L]      ]        ]I]       ]        ]        ]        ]
 ]          *--------------------------------------------------------*
 ]           0 1 234567 01234567 0 1234567 01234567 01234567 01234567
 ]                                 <------------ 31 bits ----------->
 ]           <------------------ 48 bit address -------------------->
 ]
 ]           FAI = Functional Address Indicator
 ]                 (only significant if Byte 0, bits 01 = B'11')
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 14. IBM Token-Ring Network - MAC Address Format
 o   The reserved bits are set to B'0' for locally administered addresses.
 o   Functional address indicator = B'0' indicates a functional address if I/G
     = B'1' (indicating a group address).
 o   For individual locally administered addresses, FAI must be B'0' by
     convention. This is an addressing anomaly.
 These rules yield valid address ranges as described in Figure 15 under heading
 "2.2.2.1  MAC Addressing" for any IBM Token-Ring Network adapter.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                            *------------------------------------------*
 ]                            ] I/G ] U/L ] FAI ] Definition/Range       ]
 ]         *------------------+-----+-----+-----+------------------------]
 ]         ] Individual,      ]  0  ]  0  ] 0/1 ] Mfg_Code,Serial_Number ]
 ]         ] Universally Adm. ]     ]     ]     ] (IEEE assigned)        ]
 ]         ]------------------+-----+-----+-----+------------------------]
 ]         ] Individual,      ]  0  ]  1  ]  0  ] X'4000 0000 0000' -    ]
 ]         ] Locally Admin.   ]     ]     ]     ] X'4000 7FFF FFFF'      ]
 ]         ]------------------+-----+-----+-----+------------------------]
 ]         ] Group            ]  1  ]  1  ]  1  ] X'C000 8000 0000' -    ]
 ]         ] Address          ]     ]     ]     ] X'C000 FFFF FFFF'      ]
 ]         ]------------------+-----+-----+-----+------------------------]
 ]         ] Functional       ]  1  ]  1  ]  0  ] X'C000 0000 0001' -    ]
 ]         ] Address          ]     ]     ]     ] X'C000 0000 2000'      ]
 ]         ]                  ]     ]     ]     ] (bit-sensitive)        ]
 ]         *-------------------------------------------------------------*
 ]
 ]           Functional Addresses are listed in Figure 12 under heading "2.2.2.1
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 15. Valid Address Ranges

 2.2.2.1.1  Data Transmission:  The transmission technique used in token
 passing ring LANs is BASEBAND TRANSMISSION.
 In a token-ring LAN, high-order bytes/bits are transmitted first, that is byte
 0 is transmitted before byte 1 and high-order bit 0 within a byte (of 8 bits)
 is transmitted first. This transmission order can be different for other types
 of LAN segments using a different access protocol, for example, CSMA/CD.
 Opposite transmission order may be a diagnostic consideration when evaluating
 trace information from LAN segments of different nature because of the
 possible need to reorder the bits.  The ability to reorder the bits without
 significant performance degradation, may also be a functional requirement of
 bridge products being considered for LAN segment interconnection.
 Figure 16 under heading "2.2.2.1.1  Data Transmission" shows the format of the
 information to be transmitted on a token passing-ring.
 +------------------------------------------------------------------------------
 ]
 ]
 ]     * Frame Format                                       Physical
 ]                                                          Trailer
 ]      ]<---------- Physical Header ------------>]         ]<--->]
 ]      ] ]<--------- Code Violation Protection-------------->]
 ]      ] ] ]<-------------- FCS Protection ----------------->]
 ]      ] ] ]                         ]< Information Field >] ]
 ]      *---------------------------------------------------------*
 ]      ]S]A]F]Destination]Source     ]Routing    ]         ]F]E]F]
 ]      ]D]C]C]Address    ]Address    ]Information] D A T A ]C]D]S]
 ]      ] ] ] ]   (DA)    ]   (SA)    ]    (RI)   ]         ]S] ] ]
 ]      *---------------------------------------------------------*
 ]       ] ] ]                              ]          ]     ] ] ]
 ]       ] ] Frame Control                  ]          ]     ] ] Frame Status
 ]       ] ] FF]ZZZZZZ                      ]          ]     ] ] A]C]rr]A]C]rr
 ]       ] ]                                ]          ]     ] Ending Delimiter
 ]       ] ]                                ]          ]     ] VV1VV1]I]E
 ]       ] Access Control                   ]          ] Frame Check Sequence
 ]       ] PPP]T]M]RRR                      ]          ] (4 byte CRC value)
 ]       ]                                  ] LLC protocol data unit
 ]       ]                                  ] or MAC management information
 ]       ]                                  ]
 ]       Starting Delimiter           interconnected segments, LLC only,
 ]       VV0VV000                     present when RI Indicator = B'1'
 ]                                                 (Byte 0, bit 0 of SA)
 ]
 ]     * Token format       *--------------*
 ]                          ] SD ] AC ] ED ]
 ]                          *--------------*
 ]
 ]     * Abort Delimiter    *---------*
 ]       Format             ] SD ] ED ]
 ]                          *---------*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 16. IEEE 802.5 MAC Frame and Token Format
 Explanations for abbreviations used in the above figure include:
 o   SD - starting delimiter consisting of eight bits "VV0VV0 00" and

     ED - ending delimiter consisting of eight bits "VV1VV1 I E" where:

     -   VV1VV1 refers to a '1' bit code violation (J) followed by a '0' bit
         violation (K).  This is a function of the Differential Manchester
         encoding scheme used in the Token-Ring Network.  Refer to IBM
         TOKEN-RING NETWORK ARCHITECTURE REFERENCE for a description of the use
         of Differential Manchester code violations to define starting and
         ending delimiters.
     -   I is an intermediate bit, B'0' which indicates a single-frame or the
         last frame of a multiple-frame transmission using a single token.
     -   E is an error-detected bit.  B'1' indicates existence of a code
         violation between the starting and ending delimiters, a non-integral
         number of bytes in the frame or a cyclic redundancy check (CRC) error.
 o   AC - access control consisting of eight bits "PPP T M RRR" where:
     -   PPP are priority bits (low B'000' to high B'111'). A ring station can
         use a token at a priority less than or equal to the ring station's
         allowed access priority.
     -   RRR are reservation bits (low B'000' to high B'111') which allow  a
         station with high access priority to request that a subsequent token
         be issued at the required priority.
     -   T is the token bit (B'0' = token, B'1' = frame)
     -   M is a monitor bit used to prevent continuously circulating frames or
         non-zero priority tokens.  Refer to the functions of the active
         monitor in the discussion of "2.2.2.3 Token Monitoring" for more
         details.
 o   FC - frame control consisting of eight bits "FF ZZZZZZ" where:
     -   FF are Frame Type bits (B'00' = MAC frame, B'01' = LLC frame).
     -   ZZZZZZ are Control bits (MAC buffering information or 000YYY where YYY
         indicates the intended LLC sublayer message priority).
 o   FS - frame status is an eight-bit field "A C rr A C rr" where:
     -   A is an address recognized bit (B'1' indicates that a valid station
         has recognized the destination address)
     -   C is a frame copied bit
     -   rr are reserved bits

         These bits are duplicated within the field because they not covered by
         the frame check sequence protection.
 o   Any originating ring station can abort a frame that is being transmitted
     at any time by transmitting an ABORT DELIMITER.
 The information field in the MAC frame format has been split up into an
 optional routing information field and data.  See "6.3.2 Source Routing."  In
 an LLC frame, the data field will contain a LOGICAL LINK CONTROL PROTOCOL DATA
 UNIT (LPDU, see "3.2.2.3 LLC Protocol Data Unit").
 When the frame control field indicates a MAC frame (because bits 0 and 1 of
 the field are equal to B'00') the data field contains specific MAC control
 information. It consists of a major vector length (LL), a major vector
 identifier (MVID) and zero or more subvectors as shown in Figure 17 under
 heading "2.2.2.1.1  Data Transmission".  The command field within the MVID
 contains bit values (called code points) that uniquely identify the type of
 MAC frame.
 +------------------------------------------------------------------------------
 ]
 ]
 ]            *------------------------------------/ /---------------*
 ]            ] MAC  ] MAC         ] MAC         ]     ] MAC         ]
 ]            ] LLID ] Subvector-0 ] Subvector-1 ]     ] Subvector-n ]
 ]            *------------------------------------/ /---------------*
 ]            ]      ]                                 ]             ]
 ]     *------*      *----------------------* *--------*             *--------*
 ]     ]01234567 01234567 0123 4567 01234567] ]01234567 01234567  min. 2 bytes]
 ]     *------------------------------------* *-------------------------------*
 ]     ] Major Vector    ] DC ] SC ]Command ] ]    Subvector    ] Value       ]
 ]     ] Length (LL)     ]    ]    ]        ] ] Length ]   Id   ]             ]
 ]     *------------------------------------* *-------------------------------*
 ]                       <------ MVID ------>          ]        ]
 ]                          Major Vector Id            ]        *----------*
 ]                                                     ] 0                7]
 ]                  C/S  Common/Specific Indicator     *-------------------*
 ]                  R/O  Required/Optional Indicator   ]C/S]R/O]P]P]P]P]P]P]
 ]                  P    Code Point bit                *-------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 17. Token Passing Ring MAC Frame - Data Field Format
 Examples of MVID code points are X'05' to indicate an Active Monitor Present
 MAC frame, X'02' for a Beacon MAC frame, etc.  Unique MVID values for 28
 different MAC frames have been defined. A complete description can be found in
 the IBM TOKEN-RING NETWORK ARCHITECTURE REFERENCE.  Subvectors provide
 additional information depending on the specific major vector identifier.
 MAC Frames are processed according to destination and source function classes,
 including:
 o   Ring Station

     The functions necessary for connecting to the LAN and for operating with
     the token-ring protocols. A ring station is an instance of a MAC sublayer
     in a node attached to a ring.
 o   DLC_LAN_MGR

     The manager function of the data link control component activates and
     deactivates ring stations and link stations on command from the physical
     device. It also manages information transfer between data link control and
     the physical device.
 o   Configuration Report Server (CRS)

     The CRS function can reside on each ring in a multi-segment environment in
     which configuration is being monitored. This function receives
     notifications about station insertion and removal, and notifications about
     active monitor failures.
 o   Ring Parameter Server (RPS)

     The RPS function can reside on every segment in a multi-segment ring
     environment on which operational parameters are centrally managed.  It may
     provide operational values to attaching stations upon request.  For
     example, a ring station may request such parameters as ring number upon
     insertion into the ring.
 o   Ring Error Monitor (REM)

     The REM server function is present on segments for which errors are to be
     monitored or analyzed. It collects error information from LAN stations
     attached to the local ring, analyzes soft error reports and may forward
     error reports to a LAN Manager.
 o   RPL server

     The RPL server function and its RPL functional address are involved during
     the power-on process of a LAN station equipped with the remote program
     load feature.  Such a station will insert into the ring to find a control
     program server on the ring from which to download its control program and
     complete its initialization processes.

 2.2.2.1.2  The Token Passing Ring Protocol:  To transmit data on the LAN
 medium, a ring station captures a TOKEN, and sets the token bit in the access
 control field to identify that the data being transmitted is a frame.  To this
 header the transmitting station appends destination and source MAC addresses,
 data, a newly calculated frame check sequence field, and the ending delimiter
 and frame status fields.
 Any subsequent station will receive and retransmit the frame while performing
 a CRC check. Such a station is said to be in NORMAL REPEAT MODE.
 In general, a ring station in normal repeat mode checks the data in the tokens
 and frames it receives and sets the error-detected, address recognized or
 frame copied bits in a frame (bits E, A, or C) as appropriate while repeating
 the signal.  A destination station will copy the data (FRAME COPYING) and pass
 the frame on.  While processing the frame trailer, the destination station
 marks the A and C bits. Upon return to the originating ring station, the frame
 is removed from the ring and the A and C bits in the frame trailer's FS field
 are checked to see if the frame was recognized and read by the destination
 station or a bridge (this occurs for MAC frames only).  When the frame header
 is received by the originating station the originating ring station must
 release a new token, possibly at a different priority level, for another ring
 station to capture and proceed with data transmission.  The priority
 reservation bits in the access control field of the returned frame together
 with stored priority levels in the originating station determine the priority
 of the new token.  See the description of ACCESS PRIORITY later in this
 section for details.
 This protocol is called a SINGLE TOKEN protocol, since only one token can
 circulate on the ring at any time.

 2.2.2.2  Early Token Release
 If an originating station releases a new token only when the frame header has
 circulated around the ring back to the source and the frame transmission time
 is shorter than the ring transmit time, then the originating station must
 generate idles until a header is received.
 Token-passing ring LAN protocols define the length of a token to be 24 bits
 and the shortest possible MAC frame to be 200 bits long.  On a 4 Mbps
 token-ring LAN where the length of 1 bit is roughly 50 meters, a complete
 token is 1,200 meters long while the shortest frame length would be 10,000
 meters. Therefore at 4 Mbps, the percentage of potential bandwidth which
 remains idle can be extremely small (that is high bandwidth utilization can be
 maintained at higher traffic levels.)
 If, however, we consider a 16 Mbps token-ring LAN, 1 bit being 12.5 meters
 long, a complete token and the shortest possible MAC frame become four times
 smaller (300 and 2,500 meters respectively).  Now we may wish to optimize the
 utilization of the medium by reducing the idle time required by waiting for a
 header.   Obviously when moving to even higher transmission speeds, for
 example, a 100 Mbps FDDI LAN the token passing protocol must be adjusted to
 achieve better utilization of the potential bandwidth.
 The architecture provides an option called EARLY TOKEN RELEASE.  With this
 option a transmitting station will release the token after completing
 transmission of the data frame before receipt of the header of the transmitted
 frame, thereby eliminating the idle time while waiting for the header to
 reappear.  When such early release has occurred, an adapter indicator is set
 to prevent the adapter from releasing another token upon return of the frame
 header.  This allows multiple  frames, but still only ONE token to coexist on
 the LAN.
 The early token release option is enabled by default on the 16 MBPS IBM
 TOKEN-RING NETWORK.  It is an option for each station and it is not required
 that all stations implement the option.

 2.2.2.3  Token Monitoring
 Token-passing protocols provide relatively greater control and management at
 the medium access control (MAC) level than that provided by CSMA/CD protocols.
 The token passing ring protocol concepts, described in the following sections,
 are implemented in the adapters themselves.  They contribute to the
 availability, performance and manageability of a token-ring LAN.
 At any point in time, one station and only one per segment performs an ACTIVE
 MONITOR  function.  Any ring station can act as the active monitor.  Only one
 however, will have this function enabled.
 Active monitor tasks support monitoring of the token and other ring management
 functions such as:
 o   Detection and recovery of a lost token or frame, including initiation of a
     token when a ring is started.
 o   Detection and recovery of a circulating priority token or frame.
 o   Detection and recovery of multiple tokens on the ring.
 o   Detection and recovery of multiple active monitors.
 o   Timing control to ensure accurate transmission regardless of the ring
     length.
 All other ring stations are said to be STANDBY MONITORS, prepared to take over
 the active monitor function should it fail.
 The  following description summarizes how the active monitor performs its ring
 management tasks:
 o   In every transmitted token or frame, the MONITOR BIT (M) in the access
     control field is initially set to B'0'.  As the active monitor repeats a
     frame or non-zero priority token, the M-bit is set to B'1'.  If the M-bit
     had already been set to B'1', the active monitor assumes that the frame or
     token has already circled the ring once and that the originating station
     has not been able to remove the frame or priority token. The active
     monitor will purge the ring and generate a new token.
 o   To ensure that a complete (24-bit) token can be transmitted before the
     token returns to the originating ring station, the active monitor
     introduces a 24-bit ring delay.
 o   The active monitor periodically broadcasts an ACTIVE MONITOR PRESENT MAC
     frame. This forces each station on its ring to acquire the address of its
     NEAREST ACTIVE UPSTREAM NEIGHBOR (NAUN) and to initiate a number of
     control timers within each station.  This information is used when
     isolating errors on a segment.
 o   Loss of a token or frame is detected by expiration of an ANY-TOKEN TIMER
     whose time-out value exceeds the time required for the longest possible
     frame to circle the ring. The active monitor restarts this timer each time
     it transmits a starting delimiter.  Upon expiration of this timer, the
     active monitor assumes a lost token or frame, purges the ring and
     originates a new token.  The any-token timer value is defined as the sum
     of the physical trailer transmission delay plus the delay to transmit the
     longest frame.  The IEEE 802.5 name for this timer is
     Valid_Transmission_Timer.

 2.2.2.3.1  Ring Purge:  To purge the ring, the active monitor broadcasts a
 RING PURGE MAC frame (indicated by X'04' in the frame control field) before
 originating a new token.  Return of the Ring Purge MAC frame indicates proper
 signal propagation around the ring. The Ring Purge frame resets the ring
 stations to normal repeat mode, canceling or restarting all the appropriate
 timers.  The active monitor starts a Ring-Purge Timer when sending the purge
 frame. This timer will expire if the frame can't circulate and the monitor
 will enter a recovery process called CLAIM TOKEN.

 2.2.2.4  Neighbor Notification
 The NEIGHBOR NOTIFICATION PROCESS begins when the active monitor transmits an
 Active Monitor Present MAC frame to all stations on the ring (single ring
 broadcast).  The first ring station that receives the Active Monitor Present
 MAC frame copies it (if possible) and sets the address-recognized (A) and
 frame-copied (C) bits to B'1'.  It then saves the source address from the
 copied frame as its NAUN address (the address of the active monitor) and
 starts a timer called the Notification-Response timer.
 All other active stations on the ring repeat, but do not otherwise process the
 Active Monitor Present MAC frame because the frame's A and C bits have already
 been set.
 When the Notification-Response timer of the first station downstream from the
 active monitor expires, it broadcasts a Standby Monitor Present MAC frame.
 The next ring station downstream copies its NAUN address from the source
 address field of the Standby Monitor Present frame, sets the A and C bits to
 B'1', and starts its own Notification-Response timer.  When this timer
 expires, this station in turn transmits its Standby Monitor Present MAC frame.
 In this way, Neighbor Notification proceeds around the ring, with each ring
 station receiving and transmitting Standby Monitor Present MAC frames until
 the active monitor copies its NAUN address from a Standby Monitor Present MAC
 frame.  The active monitor then sets the Neighbor-Notification Complete flag
 to B'1', indicating that the process has been successfully completed.
 Neighbor-Notification thus enables a ring station to learn its NAUN address,
 and to provide its address to its downstream neighbor.

 2.2.2.4.1  Standby Monitor:  Any ring station that is not performing the
 active monitor function acts as a STANDBY MONITOR. Its purpose is to detect a
 failing active monitor and disruptions on the ring.
 Each time a token or frame is repeated, a standby monitor restarts its
 GOOD-TOKEN TIMER ( > Any-token timer) to verify the presence of an active
 monitor.
 A second timer, the RECEIVE-NOTIFICATION TIMER, is restarted by a standby
 monitor each time it copies an ACTIVE MONITOR PRESENT MAC frame.
 If any of these two timers expires, the standby monitor station will initiate
 the token-claiming process.

 2.2.2.4.2  The Token-Claiming Process:  This process, also called the
 Monitor-Contention Process, is the procedure by which ring stations elect a
 new active monitor.  This process is started upon any of the following
 conditions by:
 o   The active monitor detecting
     -   Loss of signal
     -   The Active Monitor Present MAC frame doesn't return
         (Receive-Notification Timer expires)
     -   Failure of Ring-Purge MAC frames to return completely (Ring Purge
         Timer expires)
 o   A standby monitor detecting
     -   Loss of signal
     -   Absence of active monitor's token management functions (good_token
         timer expires)
     -   Missing Neighbor_Notification process (Receive_Notification_Timer
         expires)
 o   A ring station attaches to the ring and does not detect an active monitor
     (for example, when it is the first station on the ring).
 The ring station detecting one of these conditions enters Claim-Token-Transmit
 mode by broadcasting a CLAIM TOKEN MAC frame and repeating it at a defined
 interval.  Each participating ring station (9 under heading "2.2.2.4.2  The
 Token-Claiming Process")

 ---Footnote---
 (9) Every ring station contains an option that indicates whether it will
 participate in token claiming.  The default is not to participate.  However, if
 the ring station detects the condition, it has to initiate the process.
 --------------

 compares the address in the Claim Token MAC frame's source address field to
 its own.

 o   If the source address is greater than the ring station's address, the
     station enters Claim Token Repeat operating mode.
 o   If the source address is less than the ring station's address, the station
     transmits its own Claim Token MAC frames.
 o   If the source address is the same as the ring station's address, it
     continues broadcasting until it has received three of its own Claim Token
     MAC frames.  This indicates that the ring is viable and the station has
     won token-claiming.
 The station then adds the token delay to the ring, purges the ring, starts its
 active monitor timers, and releases a new token. It is now the new active
 monitor.

 2.2.2.4.3  Ring Station Insertion:  This process is executed by any ring
 station when entering the ring.  It is also known as the five-phase insertion
 process:
 o   Phase 0: Lobe testing.

     A series of Lobe Media Test MAC frames is sent on the lobe wire to the
     multi-station access unit.  The signal is wrapped at the entry into the
     multistation access unit causing the frames to return to the station.
     Then the receive logic is tested. If the tests are successful, a five-volt
     DC voltage (also called PHANTOM CURRENT) is sent to open the relay and
     attach to the ring.
 o   Phase 1: Monitor check.

     The attaching station starts its Insert timer, and watches for an
     Active_Monitor_Present, Standby_Monitor_Present or Ring Purge MAC frame
     before this timer expires.  If the timer expires, token-claiming is
     initiated.  When "first station on ring", the attaching station will
     become the active monitor.
 o   Phase 2: Duplicate Address check.

     The station sends a Duplicate Address Test MAC Frame (destination address
     = source address = station's unique address). If a duplicate address is
     found (A-bit = B'1'), the station detaches from the ring.
 o   Phase 3: Participation in Neighbor_Notification

     The station learns its nearest active upstream neighbor (NAUN) and reports
     its own address to its nearest active downstream neighbor.
 o   Phase 4: Request Initialization

     A Request Initialization MAC frame is sent to the ring parameter server,
     if present (if not, default values will be used).  The ring parameter
     server responds with a Initialize_Ring_Station MAC frame.  Parameters
     which can be set are physical location, soft error report timer value,
     ring number and ring authorization level. In this way the last three
     parameters may be set to the same values for all stations on the ring.

 2.2.2.4.4  Hard-Error Detection and Reporting:  A HARD ERROR is a permanent
 fault that stops normal traffic on the ring. It is usually detected first at
 the receive side of the ring station downstream from the fault.  A change in
 ring configuration is required to bypass such a fault and to restore normal
 operation. Reconfiguration may be the result of automatic recovery or, if this
 process fails to bypass the error, it may require manual intervention.
 When a ring station detects a hard error, it starts transmitting at a
 specified time interval BEACON MAC frames until its input signal is restored
 or until it removes itself from the ring.  The detecting station also starts a
 Beacon timer.  All other stations enter Beacon_Repeat mode when they receive a
 Beacon MAC frame.
 A beacon frame identifies the address of the nearest active upstream neighbor
 of the beaconing station as well as error type information.
 When the beaconing station's NAUN has copied a number of these beacon frames,
 the NAUN will go offline and perform microcode and lobe tests. If the tests
 are successful, the station reattaches to the ring immediately. If the tests
 fail, the station stays offline.
 When the beacon timer expires in the detecting (beaconing) station, and normal
 traffic has not been restored, the station assumes that its NAUN went offline,
 found no errors and came back online. It will now go through the same process
 as its NAUN. If the tests fail, the beaconing station remains detached. If
 successful, the station reattaches immediately.  In the latter case, normal
 traffic may not have been restored during automatic recovery.  Network
 management will be informed (ref. "9.2 LAN Management and MAC Architecture")
 and manual intervention will be required. While reporting a permanent hard
 error, a set of adapter addresses is provided to identify the faulty part of
 the ring as a small FAULT DOMAIN.

 2.2.2.4.5  Soft-Error Detection and Reporting:  Intermittent faults that
 temporarily disrupt normal operation of the ring are called SOFT ERRORS. They
 are usually tolerated by error recovery procedures but they may impair normal
 ring operation if excessive or non-random.
 The most critical soft errors are monitored in each ring station by means of a
 set of counters. Every two seconds the values of the soft error counters are
 sent as a Soft Error Report MAC frame to the Ring Error Monitor functional
 address (typically residing in a bridge or LAN manager station), where the
 values for each counter are accumulated.  If a soft error counter exceeds a
 predefined threshold, a LAN Manager will be informed through its link with the
 LAN reporting mechanism.  The LAN Manager may reconfigure the ring to bypass a
 faulty node, if the fault can be located.
 Soft errors are said to be ISOLATING if a fault domain can be specified. If
 not, they are called NON-ISOLATING soft errors.

 2.2.2.4.6  Access Priority:  The following discussion applies both to 4 Mbps
 and 16 Mbps token-ring LANs and is an integral part of the token passing ring
 protocol. This access priority architecture is not applicable to the FDDI
 protocol where access priority is based upon timers rather than the contents
 of an access control field.
 As stated earlier, access priority in a token or frame is indicated the first
 three bits (PPP) of the access control field (AC). Any reservation of a
 priority level is indicated in the last three bits (RRR) of the AC field by a
 station requiring higher transmission priority.
 A ring station wishing to transmit a frame at a given priority can use any
 available token with a priority level equal to or less than the priority of
 the frame to be transmitted.  If such a matching token is not available, the
 ring station may reserve a token of the required priority in a passing token
 or frame according to the following rules:
 o   If the passing token or frame already contains a priority reservation
     higher than the desired one, the ring station must leave the RRR bits
     unchanged.
 o   If the RRR bits have not yet been set (RRR = B'000'), or indicate a lower
     priority than the desired one, the ring station will set the reservation
     bits to its required priority.
 Upon removal of a frame by its originating station, the reservation bits in
 the header are checked. If they show a non-zero value, the station must
 release a non-zero priority token. The actual priority of the new token is
 based on the priority used by the ring station for the recently transmitted
 frame, the reservation received upon return of the frame and any stored
 priority.
 A ring station originating a token of higher priority enters PRIORITY-HOLD
 STATE, (also called a STACKING STATION in the IEEE 802.5 token passing ring
 standards).
 Figure 18 under heading "2.2.2.4.6  Access Priority" lists the priority
 definitions as provided by the IBM Token-Ring Network architecture.
 This protocol option however, impacts the priority handling mechanism, since a
 new token may be transmitted by the originating station before it is able to
 verify the access control field in its returned frame.
 If the frame header was already received, the token will be issued according
 to the priority and reservation requested in the AC field of the frame and the
 resulting priority levels stored in the station.
 If the frame header has not yet been completely received by the originating
 station, the token will be released with the same priority and reserved
 priority as the transmitted frame.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                   *-----------------------------------------*
 ]                   ] B'000' ] Normal User Priority           ]
 ]                   ]        ] MAC frames that need no token  ]
 ]                   ]        ] Response type MAC frames       ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'001' ] Normal User Priority           ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'010' ] Normal User Priority           ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'011' ] Normal User Priority           ]
 ]                   ]        ] MAC Frames that need token     ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'100' ] Bridge                         ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'101' ] reserved for IBM               ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'110' ] reserved for IBM               ]
 ]                   ]--------+--------------------------------]
 ]                   ] B'111' ] Specialized Station Management ]
 ]                   *-----------------------------------------*
 ]
 +------------------------------------------------------------------------------
 Figure 18. Token Passing Ring Protocol - Priority Allocation Table
 To prevent a high-priority station from monopolizing the LAN medium and to
 make sure the priority eventually can come down again, the protocol provides
 FAIRNESS within each priority level.  Figure 19 under heading "2.2.2.4.6
 Access Priority" shows how fairness within a priority is maintained.
 -------------------------------------------------------------------------------

          0*-*       1*-*                                0*-*       1*-*
      *----]A]--------]B]----*                       *----]A]--------]B]----*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
     *-*     *------->      *-*                     *-*                *-* *-*
     ]F]        0,0         ]C]                     ]F]               0,1] ]C]
     *-*                    *-*                     *-*                <-* *-*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
      *----]E]--------]D]----*                       *----]E]--------]D]----*
           *-*       3*-*                                 *-*       3*-*

 1) Station A generates a frame with                2) Station B reserves a prio
    P,R = 0,0 using a non-priority token.              of 1 (P,R = 0,1) in the f

          0*-*       1*-*                                0*-*       1*-*
      *----]A]--------]B]----*                       *----]A]--------]B]----*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
     *-*                    *-*                     *-*     *------->      *-*
     ]F]         0,3        ]C]                     ]F]     T 3,0          ]C]
     *-*      <-------*     *-*                     *-*                    *-*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
      *----]E]--------]D]----*                       *----]E]--------]D]----*
           *-*       3*-*                                 *-*       3*-*

 3) Station D reserves a higher priority            4) Station A removes its fra
    of 3, overriding B's reservation (P,R=0,3).        token at P,R = 3,0.  A en

          0*-*       1*-*                                0*-*       1*-*
      *----]A]--------]B]----*                       *----]A]--------]B]----*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
     *-*                *-* *-*                     *-*                    *-*
     ]F]             T 3,1] ]C]                     ]F]         3,1        ]C]
     *-*                <-* *-*                     *-*      <-------*     *-*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
      *----]E]--------]D]----*                       *----]E]--------]D]----*
           *-*       3*-*                                 *-*       3*-*

 5) Station B repeats priority token                6) Station D transmits its p
    making a new reservation (P,R = 3,1).              frame with P,R = 3,1.

          0*-*       1*-*                                0*-*       1*-*
      *----]A]--------]B]----*                       *----]A]--------]B]----*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
     *-*                    *-*                     *-*     *------->      *-*
     ]F]        T 3,1       ]C]                     ]F]     T 1,0          ]C]
     *-*      <-------*     *-*                     *-*                    *-*
      ]    *-*        *-*    ]                       ]    *-*        *-*    ]
      *----]E]--------]D]----*                       *----]E]--------]D]----*
           *-*       3*-*                                 *-*       3*-*

 7) Station D removes its frame upon return and     8) Station A originates a to
    generates a token at the priority just used        level 1 (as reserved) wit
    (P,R = 3,1).  Station A is still in Priority-      and stays in Priority-Hol
    Hold state awaiting a token of the priority        the priority ultimately d
    awaiting a token of the priority
 -------------------------------------------------------------------------------
 Figure 19. Token-Passing Ring Protocol - Access Priority, No Early Token-Releas

 2.2.2.4.7  Additional Token-Passing Ring Considerations.:  Using an average
 frame size of 1000 bits to simulate the performance of a 4 Mbps token-passing
 ring LAN with 100 active LAN devices results in a maximum throughput of about
 3.6 Mbps.  The token-passing ring protocol appears to be particularly stable
 and even most efficient under high load conditions.
 The impact of increased transmission speeds, increased numbers of attached
 stations, or increased transmission distances on a token-passing LAN is
 significantly less than similar changes on a CSMA/CD LAN.  Because each
 station regenerates the signal, increased distances are easier to support,
 while transmission speed is primarily limited by the choice of media.  The use
 of bridges to provide additional device capacity and/or distance is an
 attractive growth option because the absence of collisions simplifies the
 processing requirements of bridges and maintains the deterministic
 characteristics of the protocols.
 In a token-passing ring, fairness in the access protocol and high priority
 utilization by the bridge helps avoid frame loss.  Even when a frame is
 rejected due to bridge congestion, successful recovery is simplified by the
 protocol.

 2.2.3  Basic Token-Passing Bus Concepts
 The TOKEN-PASSING BUS MEDIUM ACCESS PROTOCOL is differentiated from the
 token-passing ring protocol mainly by topology requirements and by a
 timer-based token management approach.
 In a bus topology there is no physical sequence between stations. To be able
 to pass the token from one station to its successor station in a logical ring
 fashion, specific medium access function must be provided to initiate and
 maintain the logical ring sequence allowing non-disruptive station insertion
 or removal.
 Instead of relying on a token monitor function as in the token-passing ring
 access protocol, token management is distributed among all stations involved
 in token-passing based on specific timer values and a continuous measurement
 of the traffic load on the bus.
 Some stations which do not require the ability to transmit frames are said to
 be NON-TOKEN HOLDING stations.  They can only receive frames and are bypassed
 by the access protocol at token-passing time. These stations are only allowed
 to respond to requests for acknowledgement.
 As in any token-passing protocol, a station is only allowed to transmit data
 while it holds the token.  Possession of a token can therefore be described as
 the right to transmit.
 In a token-passing bus, the appearance of a logical sequence between stations
 is provided by a concept of predecessor and successor stations.  Each station
 on the medium capable of participating in token holding establishes the
 identity of its LOGICAL  predecessor and LOGICAL  successor station
 (independent of physical arrangement on the medium) on the basis of the
 descending numerical order of MAC addresses of each station.   Thus the
 logical sequence of the stations in Figure 20 under heading "2.2.3  Basic
 Token-Passing Bus Concepts" would be A - C - D - B.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]               *-----------*              *-----------*
 ]               ]  A        ]  P = B       ]  B        ]  P = D
 ]               ]           ]  S = C       ]           ]  S = A
 ]               *-----------*              *-----------*
 ]       *-*           ] ADDR = 99                ]  ADDR = 11
 ]       ] ]------------------------------------------------------------
 ]       ] ]-----------------------------------------------------------]
 ]       *-*                  ] ADDR = 66                 ]  ADDR = 33
 ]                      *-----------*               *-----------*
 ]                      ]  C        ]  P = A        ]  D        ]  P = C
 ]                      ]           ]  S = D        ]           ]  S = B
 ]                      *-----------*               *-----------*
 ]
 ]
 ]               P = Predecessor Station
 ]               S = Successor Station
 +------------------------------------------------------------------------------
 Figure 20. Token Bus Logical Sequence of Stations
 The token is normally passed from station to its successor station using a
 short TOKEN PASS FRAME. If a station fails to pick up the token, the sending
 station uses a sequence of increasingly comprehensive recovery procedures to
 find a successor station.

 2.2.3.1.1  Frame Format:  Figure 21 under heading "2.2.3.1.1  Frame Format"
 shows the frame format as transmitted on a token-passing bus, including the
 format of a token frame.  Note the absence of access control and frame status
 fields as present in a token-passing ring MAC frame.
 +------------------------------------------------------------------------------
 ]
 ]
 ]       * Generic MAC frame format                                    Physical
 ]                                                                     Trailer
 ]        ]<------------- Physical Header -------------->]           ]<-------->
 ]        ]               ]<-------- Code Violation Protection ----------->]
 ]        ]               ]<-------------- FCS Protection ---------------->]
 ]        *---------------------------------------------------------------------
 ]        ] Preamble ] SD ] FC ]Destination ]Source      ] Data_Unit ] FCS ] ED
 ]        ]          ]    ]    ]Address (DA)]Address (SA)]           ]     ]
 ]        *---------------------------------------------------------------------
 ]                     ]    ]                                           ]     ]
 ]                     ]  Frame Control                 Frame Check Sequence  ]
 ]                     ]  FF]CCCCCC                       (4 byte CRC value)  ]
 ]                     ]                                                      ]
 ]                   Starting Delimiter                          Ending Delimite
 ]                   VV0VV000                                          VV1VV1]I]
 ]
 ]       * Token frame format
 ]
 ]        *--------------------------------------------*
 ]        ] Preamble ] SD ]00001000] DA ]SA ] FCS ] ED ]
 ]        *---------------------------------------------
 ]
 ]       * Abort Delimiter    *---------*
 ]         Format             ] SD ] ED ]
 ]                            *---------*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 21. IEEE 802.4 MAC Frame Format
 o   Preamble - a number of padding bytes used in broadband transmission by the
     receiver to acquire signal level and phase lock using a known pattern. It
     also guarantees a minimum End Delimiter (ED) to Start Delimiter (SD) time
     period to allow processing of the frame previously received.
 o   SD, ED - see token-passing ring frame format
 o   FC - FF = B'00' - MAC control frame, CCCCCC = frame type
     -   B'000000' = Claim Token
     -   B'000001' = Solicit_Successor_1
     -   B'000010' = Solicit_Successor_2
     -   B'000011' = Who_Follows
     -   B'000100' = Resolve_Contention
     -   B'001000' = Token
     -   B'001100' = Set_Successor
 o   FC - FF = B'01' - LLC_data frame, B'10' = Station_Management frame, B'11'
     = reserved.

     CCCCCC = MMMPPP, PPP = LLC sublayer message priority and MMM = MAC action:
     -   B'000' = Request_With_No_Response
     -   B'001' = Request_With_Response
     -   B'010' = Response
 o   SA, DA - 48-bit MAC address fields, see Figure 13 under heading "2.2.2.1
     MAC Addressing".
 o   Token frame format - a token is transmitted as a specific MAC control
     frame with DA = unique MAC address of the successor station and a null
     data_unit.
 When a frame is received by a station, it is checked for transmission errors.
 Invalid frames are not passed to the LLC sublayer.  A MAC frame is invalid if
 any of the following conditions occurs:
 o   The frame does not contain an integral number of bytes.
 o   The result of the cyclic redundancy check upon arrival does not match the
     contents of the FCS field.

 2.2.3.1.2  The Token-Passing Bus Protocol:  The major token-passing bus MAC
 functions cover:
 o   Ring initialization (Claim Token MAC frame)
 o   Station addition (Solicit_Successor frame)
 o   Station removal (Set_Successor frame)
 o   Recovery and management, including:
     -   Bus idle conditions
     -   Token-passing failures
     -   Duplicate token
     -   Detection of a station with a faulty receiver
     -   Duplicate addresses.
 When the network is first powered up, or after a catastrophic error, the
 logical ring needs to be initialized. This process is triggered by the
 BUS_IDLE TIMER expiring in a LAN station. The detecting station sends a CLAIM
 TOKEN MAC control frame.
 As described above, each participating station knows the address of its
 PREDECESSOR, the station that transmitted the token to it and its SUCCESSOR,
 the station to which the token should be sent next.
 After a station has completed transmitting data frames and has completed other
 logical ring maintenance functions, the station passes the token to its
 successor by sending it a token MAC control frame.  Any failure in reaching a
 successor station triggers a staged recovery mechanism, using other  MAC
 control frames (SET_SOLICITOR_1 and SET_SOLICITOR_2).  If the token holder
 does not receive a valid token after sending the token the first time, it
 repeats the token pass operation. If the successor doesn't transmit after a
 second token frame, the sender assumes that its successor has failed and sends
 a WHO_FOLLOWS MAC control frame containing its successor's address in the data
 field.  The station detecting a match between its predecessor and the address
 in the Who_Follows   frame data field will respond by sending its address in a
 SET SUCCESSOR MAC control frame.  In this way, the token holding station
 establishes a new successor excluding the failing station from the logical
 ring.
 Stations are added to the logical ring through a controlled contention process
 using RESPONSE WINDOWS, a specific interval of time common to all stations,
 and based on numerical address comparisons. The actual procedure is referred
 to as the SOLICIT_SUCCESSOR PROCEDURE.
 This procedure however raises a concern with respect to excessive delay
 experienced by a station before gaining access to the LAN when many stations
 attempt to insert into the logical ring and perform the solicit successor
 procedure.  The time a station has to wait between successive passes of the
 token is called the TOKEN ROTATION TIME.  To avoid an excessive TRT, every
 station measures the rotation time of the token. If the time exceeds a
 predefined value set by station management, the station will defer initiation
 of the solicit successor procedure, and verify at the next appearance of the
 token whether it is now rotating fast enough to perform the procedure.
 A station can remove itself from the logical ring simply by not responding
 anymore to the token passed to it. Ring station sequence recovery procedures
 will adjust the successor and predecessor information in the predecessor and
 successor stations respectively.
 A more efficient way of leaving the logical ring is to have the exiting
 station send a SET SUCCESSOR MAC control frame to its predecessor, containing
 the address of its successor.

 2.2.3.1.3  Access Priority:  The token-passing bus protocol provides an
 optional 8-level priority mechanism by which higher layer data frames, LLC
 sublayer or higher level protocols, are assigned to eight different SERVICE
 CLASSES according to their desired transmission priority. Service classes
 range from 0 (low) to 7 (high).
 At the access method level, there are four ACCESS CLASSES, corresponding to
 four request queues to store pending priority frames.  Access classes are 0
 (lowest), 2, 4 and 6 (highest priority).
 Token bus MAC maps the service class requested by the LLC sublayer into a MAC
 access class (service classes 0 and 1 into access class 0, service classes  2
 and 3 into access class 2, etc.).
 The purpose of this priority mechanism is to allocate bandwidth to the higher
 priority frames and to send lower priority frames only when there is
 sufficient bandwidth left. To prevent any station from monopolizing the medium
 with access class 6 frames, a station can only send class 6 frames for a
 maximum time defined by station management.  When this time expires a station
 must release the token even if it has additional class 6 frames ready to
 transmit.
 Similarly, each access class is assigned a TARGET TOKEN ROTATION TIME.  For
 each access class a station measures the time it takes the token to circulate
 the logical ring. If the token returns to a station in less than the target
 token rotation time, the station can transmit more frames of that access class
 until expiration of the TTRT. If the token takes more than the TTRT for a
 specific access class, no frames of this priority class can be sent at this
 pass of the token. The actual algorithm consists of loading the residual value
 of a token rotation timer into a TOKEN_HOLDING TIMER. If an access class's
 queue is empty or if the token_holding timer expires, the station begins to
 serve the next lower access class. When the lowest priority class is serviced
 the station performs any required logical ring maintenance operation and
 releases the token for its successor station.

 2.3  Fiber Distributed Data Interface Concepts
 Growing use of personal workstations has meant the increased use of file and
 print servers and communication gateways, to share resources between users and
 hence reduce costs. Applications have been developed that turn these concepts
 into real benefits, enabling data sharing between workstations, departmental
 processors and large mainframe hosts. As more users clamor to take advantage,
 the bandwidth requirement on the LAN keeps growing, if service levels or
 response times are to be maintained.
 Yet new application areas are now being developed. More sophisticated
 workstations with high-resolution graphic capabilities are very suitable for
 image display, enabling documents to contain pictorial information as well as
 simple text.  The amount of data that is needed to represent a single page of
 such a document, even with efficient data compression techniques, can approach
 the megabit size; moving it around takes a high bandwidth network. As
 technology continues to improve, and becomes available at cost effective
 prices, yet more sophisticated applications will be developed.
 If new applications are to be placed alongside the applications of today, then
 another order of magnitude increase in available bandwidth will be required
 within the establishment. The LAN that will provide this bandwidth is FIBER
 DISTRIBUTED DATA INTERFACE or FDDI.

 2.3.1.1.1  IBM and FDDI:  On June 19, 1990, IBM announced a Statement of
 Direction, that said:
 o   IBM would offer high-performance FDDI LAN, workstation, host attachment
     products and interconnection between FDDI, token-ring and Ethernet LANs
 o   That these products would conform to the emerging ISO 9314 standards.
 o   The most commonly used fibers, including the IBM Cabling System, would be
     supported
 o   That network management solutions for the FDDI environment would be
     provided
 o   Single-mode fiber and LASER technologies for longer transmission distances
     would be offered.
 When IBM announced the RS/6000 processor in early 1990, a statement was made
 that that machine would eventually support connection to an FDDI LAN. The IBM
 3172 Interconnect Controller Model 002 is the second product to contain an
 FDDI attachment content.
 Since there are no IBM products that can currently attach to an FDDI network,
 it is not possible to describe any IBM implementation.  For the benefit of
 those readers who wish to understand a little more about FDDI, what it looks
 like, and how it works, the next sections describe the architecture as
 currently defined within the standards.

 2.3.1.1.2  History:  FDDI has evolved from the activities of the AMERICAN
 NATIONAL STANDARDS INSTITUTE (ANSI) committee X3T9.5, which began its quest
 for a high-speed, optical fiber based communications network in 1982.
 Originally envisioned as a standard for future host-channel requirements, it
 rapidly became viewed as the next generation LAN standard, improving on, and
 drawing techniques from, the IEEE work on lower-speed LANs (50Mbps).
 As of today, the full protocol has not yet become a standard, and delay in
 this area has meant that a LAN implementing a full standardized FDDI cannot be
 built.  The following paragraphs will give an overview of the structure,
 characteristics and protocols of this architecture, and attempt to position
 today's token-ring technology with regard to this important new architecture.

 2.3.1.1.3  Structure:  FDDI describes a dual counter-rotating fiber-optic ring
 operating at 100Mbps, in many ways similar, and in some ways different, to the
 IEEE token-ring. FDDI uses a token-passing protocol, with each station having
 the chance to transmit frames when a token passes.  The algorithm that a
 station uses to decide how many frames can be transmitted is described in
 "2.3.1.1.6 Allocating FDDI Capacity." A difference between token-ring and FDDI
 is that an FDDI station can transmit multiple frames one after the other
 without releasing a token in between. In fact, the token-ring standard allows
 token-ring stations to do this also. It is an implementation decision as to
 whether to do this or not.  In order to allow fairness of medium access to
 token-ring stations, IBM has chosen not to allow multiple frames without token
 release. FDDI has other methods to ensure that stations get access to the
 ring, so multiple frames are allowed.
 In token-ring, all stations with the exception of the IBM 8220 Optical Fiber
 Converter and the IBM 8230 Controlled Access Unit attach to the ring via an
 access unit, which may be active or passive.  In FDDI, stations can attach
 directly on to the ring or through a concentrator.  A concentrator is a device
 similar in concept to an active token-ring access unit, in that it provides
 for attachment to the rings for many devices connected to lobes. However, with
 FDDI, the stations use the fiber-optic media to attach to the concentrator,
 not copper cabling as with token-ring. Since fiber-optics cannot carry a
 PHANTOM CURRENT as is used to switch the relays within the token-ring access
 units, insertion of the device into the ring is controlled by a defined
 protocol.
 FDDI uses two rings, one called the PRIMARY and the other the SECONDARY ring.
 Compared to the token-ring, the primary ring may be likened to the main-ring
 path, with the secondary ring acting as the backup ring path.
 Stations, if attaching directly, or concentrators can attach to either or both
 of these rings. In order to differentiate between stations that attach to one
 or both rings, two classes of station are defined.
 A CLASS A station attaches to both of the rings directly, while CLASS B
 stations attach to only one of the rings.  Attachment of class B stations can
 be direct or through a concentrator.
 A class A station might be a host gateway or perhaps a bridge to a lower speed
 LAN. For these stations, availability rather than cost would be the prime
 design consideration, however there is no requirement that these types of
 station must be class A.  One important fact about a class A station is that
 it should not be powered off. If it does, then, as will be seen later, the
 ring will reconfigure around it in order to remain operational. If two class A
 stations were absent from the ring, then the ring would split into two. This
 is a similar situation to that which can happen in the token-ring if two sets
 of IBM 8220 Optical Fiber Converters were both broken at the same time. Host
 gateways or LAN bridges might be expected to be continuously available, an
 attribute of a class A station.  Ordinary workstations, such as personal
 computers, which will be powered on or off would be suitable for class B
 attachment. The cost of attachment of class B stations would also be less,
 again making the approach suitable for the mass of customer installed
 workstations.
 Concentrators, in addition to the stations, are able to attach to either or
 both rings.
 A DUAL ACCESS CONCENTRATOR (DAC), as its name implies, attaches to both rings,
 while a SINGLE ACCESS CONCENTRATOR (SAC) attaches to only one. Only Class B
 stations can attach to a concentrator. A diagram illustrating this is shown in
 Figure 22 under heading "2.3.1.1.3  Structure". The figure shows class A
 stations attached directly to both rings. A dual access concentrator (DAC) is
 shown, supporting some class B station attachments, as well as a single access
 concentrator (SAC) treed off of it. Also attached to the primary ring path,
 are a direct attached class B station, and a tree of two other SACs.
 Direction of token rotation is shown by the arrows.

 -------------------------------------------------------------------------------

        *-------*                        *-------*   *------------*
        ] Class ]                        ] Class ]---] token-ring ]
        ]   A   ]     Primary ring       ]   A   ]   *------------*
  *-----+-------+---------<--------------+-------+----------*
  ] *---+-------+--------->--------------+-------+--------* ]
  ] ]   *-------*    Secondary ring      *-------*        ] ]
  ] ]    Gateway                           Bridge         ] ]
  V A                                                     V A
  ] ]                                                     ] ]
  ] ]                                                     ] ]
  ] ]   *---------------*                                 ] ]
  ] *---+---------------+-------------<-------------------* ]
  ]     ]     DAC       ]                *-------------*    ]
  *->---+-**------**----+--->----**--->--+--**->--**---+----*
        *-++------++----*        ]]      *--++----++---*SAC
          ]]      ]]             ]]         ]]    ]]
          ]]    *-++-----------* ]]         ]]  *-++-------------*
          ]]    ] ]*---<-----* ] ]]         ]]  ] ]*-----<-----* ]
          ]]    ] V   SAC    ] ] ]]         ]]  ] ]     SAC    ] ]
          VA    ] *-**->--**-* ] VA         VA  ] *-**--->--**-* ]
          ]]    *---++----++---* ]]         ]]  *---++------++---*
          ]]        ]]    ]]     ]]         ]]      ]]      ]]
 Bridge   ]]        ]]    ]]     ]]         ]]      ]]      ]]  Bridge
      *-------* *-------* VA *-------*  *-------*   VA  *-------*
      ]Class B] ]Class B] ]] ]Class B]  ]Class B]   ]]  ]Class B]
      *-------* *-------* ]] *-------*  *-------*   ]]  *-------*
          ]               ]]Bridge +-               ]]        ]
 ----+--------+----       ]]       ]Ethernet    *-------*  *----------*
      Ethernet        *-------*    ]            ]Class B]  ]token-ring]
                      ]Class B]   -+-           *-------*  *----------*
                      *-------*    ]

 -------------------------------------------------------------------------------
 Figure 22. FDDI - Station attachment
 A class A station or a dual access concentrator has a medium access control
 instance on the primary only and optionally on both the primary and secondary
 ring path. The significance of this will become clearer during the discussion
 on ring recovery.
 During normal ring operation, the secondary ring is idle with no user traffic
 being sent around it, as is the backup path in token-ring implementations.
 In order to utilize an FDDI ring as an establishment or campus backbone for
 interconnecting other LAN types, perhaps Ethernets and token-rings, bridges
 will be needed to link the slower-speed LANs to the backbone. The structure of
 an FDDI frame is different from both token-ring and Ethernet frames. The FDDI
 frame structure is illustrated in Figure 24 under heading "2.3.1.1.5  Medium
 Access Control Layer (MAC)", but for the moment, the important point is that
 the frame check sequence characters for the frame as it exists on the
 token-ring or Ethernet will be different from that on the FDDI LAN.  This
 means that the bridges will have to recalculate it as the frame passes from
 one LAN to the other. Although not necessarily important from a performance
 point-of-view, it does mean that there could be a data integrity exposure
 within the bridge.  There would be a short time when the frame was not
 protected by a frame check sequence.  A bit dropped or picked up would lead to
 the frame being carried end-to-end without the possibility of the error being
 detected.
 Another problem in obtaining complete inter-operability between Ethernet and
 token-ring attached stations is that of source and transparent bridging
 techniques being used by the different LANs. This could be solved by the
 concept of the SRT bridge. This new design for a bridge is discussed in "6.3.3
 Source Routing/Transparent Bridging Inter-operability."

 2.3.1.1.4  Architecture:  One of the prime requirements for FDDI is as a
 HIGH-SPEED ESTABLISHMENT BACKBONE to interconnect heterogeneous LANs. To this
 end, the FDDI LAN design must have reliability and capacity built in.
 Attachment cost does not have to be so carefully limited, since most of the
 cheaper workstations, would be connected to the lower speed LANs that were
 themselves bridged to the FDDI backbone.
 FDDI has satisfied these requirements by:
 o   Operating at a data rate of 100Mbps, providing lots of capacity
 o   Having a dual optical fiber ring configuration, that can be reconfigured
     by the class A stations in the event of a failure. This provides for
     reliability and recovery.
 o   Allowing stations to attach to both of the rings (more expensive) or only
     one (cheaper).
 ANSI, in defining and developing the standard was able to make much use of the
 work already done by the IEEE. To this extent, they used a similar model for
 the layering of the protocols. The structure is shown in Figure 23 under
 heading "2.3.1.1.4  Architecture".
 -------------------------------------------------------------------------------

             A   *---------------------------*
             ]   ]       IEEE 802.2          ]
     OSI     ]   ]  Logical Link Control     ]
     Layer 2 ]   ]---------------------------+--------------*
             ]   ]          MAC              ]              ]
             V   ]  Medium Access Control    ]              ]
           - - - ]---------------------------]              ]
             A   ]          PHY              ]   Station    ]
     OSI     ]   ]    Physical Protocol      ]  Management  ]
     Layer 1 ]   ]---------------------------]              ]
             ]   ]          PMD              ]              ]
             ]   ] Physical Medium Dependent ]              ]
             V   *------------------------------------------*
 -------------------------------------------------------------------------------
 Figure 23. FDDI Architecture
 The FDDI standard assumes the use of the IEEE 802.2 logical link standard; it
 does not attempt to define it as part of FDDI.

 2.3.1.1.5  Medium Access Control Layer (MAC):  In this layer, FDDI borrows
 very extensively from the techniques used by the IEEE, particularly the 802.5
 token-ring specification.
 FDDI uses a token access protocol; stations are aware of their nearest active
 upstream neighbor, and with Class A stations, their neighbor on the secondary
 ring as well.  There are similar processes for ring monitoring, such as the
 CLAIM TOKEN and BEACONING PROCESS.
 As with token-ring, when an FDDI station wishes to transmit a frame, it must
 wait for a token to arrive. In the token-ring architecture, the transmitting
 station flips a bit in the token to indicate that it is a token no longer, and
 appends the data to this frame header.  With FDDI, the token is removed from
 the ring by the transmitting station before actual frame transmission begins.
 The frame size on an FDDI LAN is limited by clocking constraints to 4500
 bytes. At the FDDI data rate, and given the fact that an FDDI ring can be
 physically very large, it is extremely likely that the frame will be
 physically shorter than the length of the ring. For token-ring at 16Mbps, IEEE
 802.5 has specified a concept known as EARLY TOKEN RELEASE which is designed
 to prevent wasting bandwidth on the ring. This has been described in "2.2.2.2
 Early Token Release" . FDDI uses a similar concept. A token is transmitted
 immediately behind the last data frame, whether or not the head of the frame
 has returned to the sending station. This token is available for any other
 station to use.
 The frame and token structure on an FDDI LAN is shown in Figure 24 under
 heading "2.3.1.1.5  Medium Access Control Layer (MAC)".
 -------------------------------------------------------------------------------

 FDDI FRAME

           SFS               FCS Protected                EFS
      <----------->]<-------------------------------->]<------->
     *----------------------------------------------------------*
     ]   PA   ] SD ] FC ] DA ] SA ]  Information  ]FCS] ED ] FS ]
     *----------------------------------------------------------*

   PA  Preamble - used for clock synchronization - 64 bits
   SD  Starting delimiter -
   FC  Frame Control
   DA  Destination Address
   SA  Source Address
   FCS Frame Check Sequence - 32 bit result of a CRC check
   ED  Ending Delimiter
   FS  Frame Status - address recognized, frame copied and error detected
                      bits

   SFS Starting Frame Sequence
   EFS Ending Frame Sequence

 FDDI TOKEN

    *-----------------------*   FC = 1000 0000 Unrestricted token
    ]   PA   ] SD ] FC ] ED ]   FC = 1100 0000 Restricted token
    *-----------------------*

 FRAME CONTROL

         *-------------*
         ] CLFF ] ZZZZ ]
         *-------------*

    C    - Class bit                  0 = Asynchronous  1 = Synchronous
    L    - Length of address fields   0 = 48 bit  1 = 16 bit
    FF   - Format    00 = MAC or SMT frame
                     01 = LLC frame
                     10 = Implementation dependent
                     11 = Reserved
    ZZZZ - Control bits  Dependent on frame type

 -------------------------------------------------------------------------------
 Figure 24. FDDI Frame and Token Formats
 Stations on an FDDI ring can use 16 or 48 bit addressing. If a station uses 16
 bit addressing, it must be able to recognize the 48 bit all-stations broadcast
 address of a 48 bit station. The converse is also true for a 48 bit station.
 Stations addressed in the two different ways must also be able to participate
 in all the station management (SMT) and MAC protocols on the ring.

 2.3.1.1.6  Allocating FDDI Capacity:  Because the token is always released
 before the frame header has returned, the priority reservation scheme that is
 used in the token-ring architecture to give stations priority access to the
 ring cannot work in FDDI. Additionally, FDDI is designed to give far greater
 control over the use of the ring capacity to connecting stations. The
 mechanism that is used is heavily dependent on timers within each station.
 FDDI defines two classes of traffic:
 SYNCHRONOUS
           for which a guaranteed bandwidth is required; that is a station must
           gain access to the ring, and transmit its frames within a specified
           time period. Such an application might be a manufacturing control
           application, where a robot arm needs to be accurately controlled by
           a processor.
 ASYNCHRONOUS
           traffic will only be transmitted when the load on the ring drops
           below a specified level. Such traffic might be file transfer where
           overall access or response time is not quite such an issue.
 To control the amount of each kind of traffic that can be transmitted by a
 station, FDDI implements a TIMED TOKEN ACCESS PROTOCOL. Stations expect to see
 a token within a specified time interval. This interval is known as the TARGET
 TOKEN ROTATION TIME (TTRT).  All stations have the same value for TTRT set
 within them. The value is determined when a station initializes itself on the
 ring.
 Each station measures the time between successive appearances of a token. The
 stations uses a TOKEN ROTATION TIMER (TRT).  to do this.
 When a token passes a station, the TRT is set to the value of the TTRT and
 starts to count down. If the TRT timer expires before the next token is seen,
 a counter called the LATE COUNTER is incremented. The token is said to be
 late. Under normal circumstances, the token should reappear within the target
 time. The token is then said to be EARLY.
 Each time a station sees a token, three things happen:
 o   The station may start to transmit synchronous frames
 o   If the TRT has not expired, that is the token was early, the remaining
     time is stored in the TOKEN HOLDING TIMER (THT).  The THT is therefore the
     amount of time by which the token was early.
 o   The TRT is reset to the value of TTRT and allowed to start running down
     again.
 The station is allowed to transmit synchronous frames until a time allocated
 for synchronous data transmission expires (the synchronous allocation timer).
 This timer value may be different at each station (it may be zero at some
 stations if they have not been enabled by an application for synchronous
 transmission), but the sum value of all the synchronous allocation timers on
 active stations must always be slightly less than the target token rotation
 time. It is up to the station management protocols to make sure that this is
 so.
 When the timer expires, or all synchronous frames are transmitted, the station
 may be allowed to transmit asynchronous frames. The decision is based on the
 value of the LATE COUNT. If the count is at zero, asynchronous frames can be
 transmitted for the length of time that was stored in the token holding timer.
 When this timer runs down to zero, transmission must stop, and a token must be
 released.
 Meanwhile, the TRT is steadily running down. It has been doing so during both
 synchronous and asynchronous transmission. If both of these transmissions were
 stopped because of timer expiration (synchronous allocation and token holding)
 and assuming that other stations have frames to send, the TRT will almost
 certainly expire before the token is seen again. The token is late; the late
 counter will be incremented, there will be no value to put in the token
 holding timer, and the station will not be allowed to send any asynchronous
 frames the next time it does see the token. In a way, the station has paid a
 penalty for having had so much traffic to send.  This penalty only applies to
 asynchronous traffic however; a station may always transmit synchronous
 traffic when it sees a token.
 When the token next arrives early, the late counter is decremented.  When the
 value gets to zero, the station will be able to transmit asynchronous traffic
 once more.
 When this operation is considered across all stations on the ring, the
 capacity allocation algorithm is attempting to keep the actual token rotation
 time less than the target. Since synchronous traffic can always be sent, the
 mechanism guarantees an amount of bandwidth to the synchronous traffic.
 Asynchronous traffic is only sent when there is spare capacity on the LAN, and
 fairness of station access is maintained.
 In order to summarize this algorithm, we will present an example.  Suppose
 that:
 o   TTRT is set at 80 milliseconds
 o   The synchronous allocation timer is set to 10 milliseconds
 Now we will follow it through:
 1.  A token arrives
 2.  TRT is set to TTRT (TRT contains 80)
 3.  No traffic to send, so token is released
 4.  Traffic starts to get queued for sending within the station
 5.  The token reappears - TRT has got down to 30, that is there was an
     interval of 50 milliseconds between step 1 and 4.
 6.  The token is early
 7.  The value of 30 is placed in the token holding timer
 8.  TRT is reset to 80 and starts to run down
 9.  Synchronous traffic is sent for 10 milliseconds (synchronous allocation
     timer)
 10. TRT now reads 70
 11. Asynchronous traffic is sent for 30 milliseconds (token holding timer)
 12. TRT now reads 40
 13. A token is released
 14. Last time, the token took 50 milliseconds to go around the ring.  If any
     other stations have traffic to transmit, it will take longer.
 15. TRT expires, the late counter is incremented to a value of 1.
 16. More asynchronous traffic is queued within the station
 17. TRT is reinitialized to 80, and runs down
 18. The token reappears 15 milliseconds later
 19. This time the token has taken 55 (40+15) milliseconds to go around.  TRT
     has the value 65 in it. The token appears to be early, but the late count
     still has a value of 1 in it, so the token is late. The station can
     transmit synchronous traffic, but no asynchronous. If there is no
     synchronous traffic to send, the token passes by.
 20. The late count is decremented to zero
 21. The token reappears after 50 milliseconds
 22. TRT now has a value of 15 in it, the late count is zero, so the station
     can transmit its asynchronous traffic for 15 milliseconds.
 For asynchronous traffic two other mechanisms may also operate.  These are:
 o   Restricted token

     This allows two stations, communicating with asynchronous traffic to take
     all the asynchronous bandwidth available on the LAN.  When a station
     wishes to initiate this, it transmits its asynchronous frames, and
     releases a RESTRICTED TOKEN.  Only the last station to receive an
     asynchronous frame can use the restricted token for asynchronous traffic,
     so the two stations can go on transmitting to each other. The restricted
     token is useable by any station with synchronous traffic to send.
     Therefore the guarantee of synchronous bandwidth remains.
 o   Priority

     Asynchronous traffic can be allocated to one of eight priority levels.
     When there is time available for asynchronous frame transmission, the
     frames are sent in priority order, level 7 down to 0.
 Using all these mechanisms, FDDI is able to cope with traffic needing a
 defined amount of bandwidth, and also support the "bursty" traffic whose
 response time requirement is less defined.  It also allows for those
 applications where a prolonged and restricted communication between partners
 is required.

 2.3.1.1.7  Physical Layer (PHY):  As in the IEEE standards, the physical layer
 specifies the signalling rate, encoding and clocking of the LAN.  For FDDI,
 the data rate on the ring is 100Mbps.
 The IEEE token-ring standard specifies the use of Differential Manchester
 Encoding. This method of coding means that the signal frequency on the ring is
 twice the nominal data rate. For a 16Mbps token-ring, this rate would be 32
 million signalling elements a second or 32M baud. If this coding technique
 were used for 100Mbps operation, this would mean that the signalling rate
 would have to be 200Mbaud, which would put additional cost implications on the
 technology used and drive distances obtainable.
 So, a different technique is used.  The datastream is transmitted as a series
 of 4 bit symbols, with each symbol being encoded within a 5 bit pattern. This
 is known as 4B/5B encoding, and means that the signalling rate need only be
 125M baud.  Since 4 bits represents 16 digits, and 5 bits 32 digits, 16 of the
 5 bit codes are redundant. These codes can be used for special purposes, such
 as delimiting the start and end of frames.
 In order to improve reception of the symbols by a station, these 5 bit
 patterns are additionally encoded using NON-RETURN TO ZERO INVERTED (NRZI).
 This technique means that a bit ( 0 or 1 ) is indicated by not changing (0) or
 changing (1) the polarity of the signal (light on or off) at each bit clock
 time. This differential technique improves the accuracy of signal reception,
 as well as helping to maintain synchronization between transmitter and
 receiver.
 In the token-ring, master clocking is done by the ACTIVE MONITOR. In the FDDI
 standard, responsibility for the clocking rests with all stations, primarily
 because the clocks need to run very fast. The problems of synchronizing
 individual clocks to a master would lead to expensive circuitry. Therefore
 each station has an autonomous clock, independent of all others, with
 synchronization maintained by the NRZI coding technique.
 FDDI defines a maximum of 500 stations attaching per ring.

 2.3.1.1.8  Physical Medium Dependent Layer (PMD):  This layer is new if
 compared with the IEEE standards. It is used to specify the fiber type and
 size used by FDDI, the connectors, and the wavelength of the light beam that
 is transmitted down the fiber.  The standard fiber is a multi-mode fiber of
 62.5/125 micron, (10(-6) meters) although fiber sizes of 50/125, 82.5/125, and
 100/140 microns are listed as alternatives, as well as single-mode fiber.
 By selecting a wavelength of 1300nm (nanometers or 10(-9) meters), the Light
 Emitting Diode (LED) is still suitable as an optical transmission device.  The
 wavelength is not the same as that used by the IBM 8219 or 8220 optical fiber
 converters (850nm); at the FDDI signalling rate that wavelength would begin to
 lose transmission distance. Use of a longer wavelength (1550nm) would require
 a more expensive laser transmitter, so the selection of 1300nm does mean that
 the cheaper LED technology can still be used.
 FDDI has defined that the maximum fiber drive distances between stations shall
 be 2 kilometers (2000 meters). If a ring contained all 500 stations at the
 maximum distance apart, the ring would span 1000 kilometers.

 2.3.1.1.9  Station Management (SMT):  Station Management is perhaps the single
 most important function within the FDDI architecture and one to which IBM has
 made significant contributions within the standards-making body.  It defines
 the protocols that stations use to intercommunicate, so as to set their
 timers; the target token rotation timer or their synchronous allocation timers
 for example.  Without a consistent set of protocols which are used by all
 stations that attach to the ring(s), it is impossible for FDDI to deliver the
 function, capacity and performance for which it was designed.
 Station management is also responsible for describing what the MANAGED OBJECTS
 within an FDDI station should be. A discussion on these concepts can be found
 in "2.4 LAN Station Management."

 2.3.1.1.10  Ring Reconfiguration:  As with the token-ring, the secondary FDDI
 ring is available to establish an alternate ring path should a break or other
 disruption occur on the network. For example, a failing or inactive
 dual-attached station or concentrator will be detected by adjacent units both
 upstream and downstream of the failed station. The stations detecting the
 failure can wrap the primary path to the secondary path, thus completing the
 ring via the secondary path, and bypassing the failed station or concentrator.
 This is shown in Figure 25 under heading "2.3.1.1.10  Ring Reconfiguration".
 The default mode of operation is for a dual-attached station to execute a wrap
 upon detection of an error on either the primary or secondary path. Although
 the secondary ring is idle in normal operation, the optional secondary ring
 MAC instances contained within the dual attached stations are able to detect
 failures. The situation is dissimilar to that seen in the token-ring
 environment with the IBM 8220 Optical Fiber Subsystem, and the IBM 8230
 Controlled Access Unit.  The Station Management function can detect certain
 types of physical errors, such as broken fiber, faulty connection and a bad
 receiver or transmitter, without a secondary ring MAC instance.
 -------------------------------------------------------------------------------

                               *------------------------*
                               ]      Class A Node      ]
                               ] Wrap        ------*    ]
                               ]    *-*        --* ]    ]
                               ]    ] ]          ] ]    ]
                               *------------------------*
                                  *-----*      *-----*
                                    ] ]          ] ]
                      Concentrator  ] ]          ] ]
   *---------*         *-------*    ] ]          ] ]
   ] Class B ]         ]       ] PI V A          ] ]
   ] Node    ]-*     *-]       ]-*  ] ]          ] ]
   ]       *-] ]--<--] ]-------] ]--* ]          ] ]
   ]       *-] ]-->--] ]-*   *-] ]----*
   ]         ]-*     *-] ]   ] ]-*              Break
   ]         ]         ] ]   ] ] SO
   *---------*         ] ]   ] ]                 ] ]
                       ] ]   ] ]                 ] ]
   *---------*         ] ]   ] ]                 ] ]
   ] Class B ]         ] ]   ] ]                 ] ]
   ] Node    ]-*     *-] ]   ] ]                 ] ]     *---------*
   ]       *-] ]--<--] ]-*   ] ]                 ] ]     ] Class A ]
   ]       *-] ]-->--] ]-*   ] ]                 ] ]   *-] Node    ]
   ]         ]-*     *-] ]   ] ]                 ] *---] ]----*    ]
   ]         ]         ] ]   ] ]                 *-----] ]--* ]    ]
   *---------*         ] ]   ] ]                       *-]  ] ]    ]
                       ] ]   ] ]                         ]  ] ]    ]
   *---------*         ] ]   ] ]    Secondary Ring       ]         ]
   ] Class B ]         ] ]   ] ]    ]                    ]         ]
   ] Node    ]-*     *-] ]   ] ]-*  V                  *-] Wrap    ]
   ]       *-] ]--<--] ]-*   *-] ]----------<----------] ]--*      ]
   ]       *-] ]-->--] ]-------] ]---------->----------] ]--*      ]
   ]         ]-*     *-]       ]-*  A                  *-]         ]
   ]         ]         ]       ]    ]                    ]         ]
   *---------*         *-------*    Primary Ring         *---------*

 -------------------------------------------------------------------------------
 Figure 25. FDDI Dual Ring Reconfiguration

 2.3.1.2  FDDI Standards
 As has been stated, the FDDI architecture is divided into four functional
 parts:
 o   Physical Medium Dependent (PMD)
 o   Physical  (PHY)
 o   Medium Access Control (MAC)
 o   Station Management (SMT)
 At the time of publication of this document, then:
 o   PMD is an International Standard - ISO 9314/3
 o   PHY is an International Standard - ISO 9314/1
 o   MAC is a Draft International Standard - DIS 9314/2
 o   SMT is being balloted as a draft ANSI standard.

 2.3.1.2.1  Token-Ring Comparison:  It should be apparent from the previous
 text that there are many similarities between the FDDI standard and the IEEE
 802.5 token-ring standard. There are also some differences, many of which are
 required by the increase in speed of FDDI and hence timing considerations.
 The differences are summarized in Figure 26 under heading "2.3.1.2.1
 Token-Ring Comparison" .
 -------------------------------------------------------------------------------

  *-------------------------------------------------------------------*
  ]                     ]     Token-Ring       ]       FDDI           ]
  ]---------------------+----------------------+----------------------]
  ] Speed               ]  4/16 Mbps           ]  100 Mbps            ]
  ]                     ]                      ]                      ]
  ] Standard            ]  IEEE 802.5          ]  ANSI X3T9.5         ]
  ]                     ]                      ]                      ]
  ] Medium              ]  shielded copper     ]  optical fiber       ]
  ]                     ]  optical fiber       ]                      ]
  ]                     ]                      ]                      ]
  ] Optical fiber       ]  50/125              ]  typical 62.5/125    ]
  ]                     ]  62.5/125            ]  optional 50/125,    ]
  ]                     ]  100/140             ]  50/100 and 9/125    ]
  ]                     ]                      ]                      ]
  ] Number of active    ]  max. 260            ]  max. 500            ]
  ] stations            ]                      ]                      ]
  ]                     ]                      ]                      ]
  ] Distance between    ]  max. 2km            ]  max. 2km (multimode)]
  ] stations            ]  (with converters)   ]  longer w/singlemode ]
  ]                     ]                      ]                      ]
  ] Max. frame length   ]  17997 byte          ]  4500 byte           ]
  ]                     ]                      ]                      ]
  ] Data Encoding       ]  Manchester          ]  4B/5B  NRZI         ]
  ]                     ]        Differential  ]                      ]
  ]                     ]                      ]                      ]
  ] Clocking Control    ]  Centralized         ]  Distributed         ]
  ]                     ]                      ]                      ]
  ] Recovery            ]  More centralized    ]  Distributed         ]
  ]                     ]                      ]                      ]
  ] Bandwidth allocation]  Priority/reservation]  Timed token         ]
  ]  traffic            ]   Asynchronous       ]     Synchronous      ]
  ]                     ]                      ]     Asynchronous     ]
  ]                     ]                      ]                      ]
  ] Consecutive frames  ]  No - one per station]  Multiple            ]
  ]                     ]       per token      ]                      ]
  ]                     ] (IBM Implementation) ]                      ]
  *-------------------------------------------------------------------*

 -------------------------------------------------------------------------------
 Figure 26. FDDI and Token-Ring - Architectural Differences

 2.3.1.2.2  Migration:  The FDDI standard is just beginning to stabilize enough
 to allow a full implementation to be considered. Although some companies are
 offering FDDI implementations at this time, it may be yet some time before a
 common implementation can be adopted by all vendors. Many users may not have
 an immediate need for the high bandwidth offered by FDDI, and may be wise to
 consider a migration strategy that begins with the 16Mbps token-ring. Due to
 the underlying similarity of the infrastructures (fiber type and topology),
 migration would be simple once the FDDI standard is complete and stable.
 A key factor to consider in migration to FDDI is network management.  The IBM
 LAN Network Manager, coupled with NetView, is one of the most advanced LAN
 management tools available on the market today.

 2.4  LAN Station Management

 2.4.1  Open Systems Management
 As has been described in "2.0 LAN Technology" LANs have varying degrees of
 management capability built into them by virtue of their architecture.
 Dependent particularly on their PHYSICAL TOPOLOGY and MEDIUM ACCESS CONTROL
 (MAC) layer implementation they can offer various amounts of essentially
 problem determination information as input to the management process. For
 instance, LANs that implement the IEEE 802.5 token-ring standard are able to
 indicate where a ring is broken because of the FAULT DOMAIN, a concept that
 would be impossible without the inclusion of "ring poll" and "nearest active
 upstream neighbor" (See "2.2.2.4 Neighbor Notification") in the MAC
 architecture.
 However, as the sophistication and power of stations attaching to LANs grows,
 as well as the number of stations and hence applications running on them,
 there is a growing need to provide much more management function than the
 answer to the question: "Is the LAN broken, and if so, where?"
 Additionally, LANs have many of the characteristics of open systems.
 Standards bodies have been increasingly active during the architectural and
 development phases of LAN technology to make sure that a particular
 implementation is sufficiently well described so that it can be attached to
 different manufacturers' equipment.
 Within the scope of Open Systems Interconnection (OSI), network management has
 been defined to include the following five areas:
 o   Fault Management

     How much problem determination is needed to be done? It may be very useful
     to know where the LAN is broken, or if it is suffering a high rate of
     recoverable errors, but what happens if an application simply stops
     communicating with its partner? How does the person responsible for
     resolving problems proceed when the medium appears to be working
     correctly?

     Fault management may be summarized as detecting, analyzing, correcting and
     tracking events and incidents in the network operation.
 o   Configuration Management

     How does the management process know what the stations really are;
     intelligent workstations, gateways, servers? How does it know what the
     serial numbers of those machines are, where they are physically located,
     and where they are plugged into the LAN? How does the management process
     know what the current operational parameters of the network are?

     How do applications know on which station their partner application
     resides? Does this information have to be defined to them, or do they have
     some way to dynamically find out, for example by using names?  NAME
     MANAGEMENT  is an integral part of OSI configuration management.

     This can be summarized as managing the physical and logical
     "relationships" among the networking resources.
 o   Performance Management

     How do we determine the utilization of the LAN by individual stations?
     Which stations are the heaviest users of the LAN, and what applications
     are they using? How do we make the decision as to whether to split the
     application across multiple stations, or buy a more powerful machine?

     Performance management collects performance data, tunes, distributes
     workloads and enables capacity planning.
 o   Accounting Management

     What is the basis for charging for the use of the common transmission
     medium so that the costs of providing the service can be offset against
     usage?
 o   Security Management

     How is access to the LAN controlled? What is to stop someone from plugging
     a station into the LAN and "stealing" the data flowing on that LAN? What
     are the security implications?
 In order to facilitate these functions, there is a need for some kind of
 management application, working in the stations, to maintain information,
 update counters, set and reset parameters, and to make this information
 available to a central management machine. It would also be desirable if the
 information kept at each station were itself standardized, so that different
 station management applications (perhaps obtained from different vendors) had
 identical function, and were thus able to provide coherent LAN-wide
 information.  As spontaneous events occur in these stations, then some form of
 notification process is also required, such that a central LAN management
 station can be kept aware of what is going on.
 So, if the management function is to be readily available on any LAN station,
 whatever its type and make, and an ability for a central management machine to
 monitor all stations is to be provided, then it would seem sensible to adopt
 techniques that are not vendor proprietary, but which follow those described
 by OSI.
 OSI Network Management is not completely defined for "system resources", (that
 is the stations or applications); it is defined for the interconnection of
 them, and provides a model for the management process.
 It also provides a set of terminology that will be useful to understand before
 continuing. The full set of definitions is well described in another ITSC
 publication,  ISO STANDARDS AND OSI/COMMUNICATIONS SUBSYSTEM IMPLEMENTATION
 FOR OSI SYSTEMS MANAGEMENT AND THE DIRECTORY SERVICE, an "IBM Internal Use
 Only" publication, but for the benefit of the reader, the relevant definitions
 are given here.
 The MANAGEMENT PROCESS  of a communications environment is an
 information-processing application. Since a network environment is
 DISTRIBUTED, the individual components of the process are themselves
 distributed. Management processes are categorized as:
 o   MANAGING PROCESS is that part of a distributed application process that
     has responsibility for one or more management activities.
 o   AGENT PROCESS  is that part of the distributed application process that,
     at the request of a managing process, manages associated "managed
     objects".
 MANAGED OBJECTS  are data communications resources that exist independently of
 their need to be managed. Examples could include LAN attachment cards, logical
 link connections, and timers.
 MANAGEMENT OPERATIONS  are effected through the use of "managed objects". The
 agent processes perform the management functions upon receipt of directives
 specifying management operations on managed objects.
 NOTIFICATIONS  are produced by the agents as the result of unsolicited events
 that occur within the managed objects that they control.
 This structure is illustrated by Figure 27 under heading "2.4.1  Open Systems
 Management".

              Open System 1
              *-------------------------------*
              ]                               ]
              ]    *--------------------*     ]
              ]    ]                    ]     ]
              ]    ]  Managing Process  ]     ]
              ]    ]                    ]     ]
              ]    *--------------------*     ]
              ]             A  A              ]
              *-------------+--+--------------*
                            ]  ]
      Management Operations ]  ]
                            ]  ]
                            ]  ] Notifications
              Open System 2 ]  ]
              *-------------+--+--------------*
              ]             V  ]              ]
              ]    *--------------------*     ]
              ]    ]                    ]     ]
              ]    ]    Agent  Process  ]     ]
              ]    ]                    ]     ]
              ]    *--------------------*     ]
              ]               A               ]
              ]               ]               ]
              ]               V               ]
              ]  *-------------------------*  ]
              ]  ]Managed Objects          ]  ]
              ]  ] *--*  *--*  *--*  *--*  ]  ]
              ]  ] ]  ]  ]  ]  ]  ]  ]  ]  ]  ]
              ]  ] *--*  *--*  *--*  *--*  ]  ]
              ]  *-------------------------*  ]
              ]                               ]
              ]                               ]
              *-------------------------------*
 Figure 27. Interactions between Management Processes
 OSI provides a protocol that allows an application running on a central
 management machine to communicate with another application on a managed
 machine in order to set parameters, obtain information and be notified of
 spontaneous events.  This protocol is called CMIP or COMMON MANAGEMENT
 INFORMATION PROTOCOL and will be discussed below.

 2.4.1.1.1  Common Management Information Protocol:  CMIP is an Open Systems,
 application layer protocol that provides the ability to send commands and
 obtain responses between management applications.  It provides a set of
 services that themselves are defined by COMMON MANAGEMENT INFORMATION SERVICES
  or CMIS.
 These services are:
 o   GET - Get specific information and respond with it.
 o   SET - Set a parameter (and confirm that it has been done).
 o   ACTION - Perform some action(s) (and respond with the result).
 o   CREATE - Used to create thresholds (for instance error/traffic ratio).
 o   DELETE - The opposite of CREATE.
 o   EVENT - A notification that something has happened, that is an unsolicited
     event, and hence is being reported. In certain cases, this notification
     may require a response, and this is termed a CONFIRMED EVENT.
 The CMIP protocol is itself conveyed by another OSI protocol, REMOTE
 OPERATIONS (ROS). ROS provides a vehicle for the CMIP communication and itself
 provides four commands. These are:
 o   INVOKE - Requests that an operation be performed.
 o   RESULT - Reports the successful completion of that operation.
 o   ERROR - The request was not completed successfully.
 o   REJECT - Used to reject the request.
 CMIP/ROS uses connection-oriented services.

 2.4.1.1.2  A Model for LAN Station Management Figure 28 under heading
 "2.4.1.1.2  A Model for LAN Station Management" is an architectural model for
 the internal management of LAN stations, that is the agent process.  It is a
 subset of the OSI model that describes the management of the communication
 system over the complete seven layers of the OSI reference model, but of
 course restricted to the two layers that are defined within a LAN.
 -------------------------------------------------------------------------------

    *-------------------------------*       -----*          *------------
    ]                               ]            ]          ]
    ]  AGENT PROCESS             ---+-----------------------+-->
    ]                               ]       ROS(CMIP)       ]
    ]                            <--+-----------------------+---
    ]                               ]            ]          ]
    ]                      A        ]            ]          ]  MANAGING
    ]       *--------------+--------*            ]          ]  PROCESS
    ]       ]      *-------+--------* --------   ]          ]
    ]       ]      ]     ] V   **   ]            ]          ]
    ]       ]<---->] LME ] LLC ** **]            ]LAN       ]
    ]       ]      ]     ]        **] OSI        ]Station   ]
    ]       ]      ]-----+----------] Layer 2    ]          *------------
    ]       ]      ]     ]      **  ]            ]
    ]       ]<---->] LME ] MAC  ****]            ]
    ]       ]      ]     ]        **]            ]
    ]       ]      ]-----+----------] --------   ]
    ]       ]      ]     ]     **   ]            ]
    ]       ]<---->] LME ] PHY ** **] OSI        ]
    ]       ]      ]     ]        **] Layer 1    ]
    *-------*      *----------------*       -----*

      ** Managed Object
      **

 -------------------------------------------------------------------------------
 Figure 28. A Model for LAN Station Management
 An LME or LAYER MANAGEMENT ENTITY  exists for each layer of the OSI model as
 used by the LAN. An LME provides an interface to the individual layers for
 obtaining information about, and effecting changes to, the managed objects
 within the layer.  Bidirectional communication takes place between the LMEs
 and agent process.
 As well as the need for the agent process to pass its accumulated data to a
 central machine (the managing process), and be able to respond to management
 commands, there might also be a need for two Agents to communicate with each
 other. For instance, suppose that an established data link between two
 applications breaks. Although this might have been caused by a number of
 factors, it would be expected that both agent processes, one at each end of
 the link, would be notified.  The two agent processes on either end of the
 data link connection communicate only to exchange a correlator that both use
 in subsequent events.  Both ends send the reports, and the correlator is used
 by the managing process to correlate the two reports.  The events from each
 side gives a different perspective to the problem and could indicate which
 side was causing the problem.
 The following figures, Figure 29 under heading "2.4.1.1.2  A Model for LAN
 Station Management" and Figure 30 under heading "2.4.1.1.2  A Model for LAN
 Station Management" , show these possibilities.
 -------------------------------------------------------------------------------

    *--------------------*
    ] Agent Process      ]     ROS(CMIP)     *--------------------*
    ]                    ] <---------------> ]  Managing Process  ]
    ]    *---------------*                   ]                    ]
    ]    ] *-------------*                   ]                    ]
    ]    ] ]LME ] LLC    ]                   ]                    ]
    ]    ] ]----+--------]                   ]                    ]
    ]    ] ]LME ] MAC    ]                   *--------------------*
    ]    ] ]----+--------]
    ]    ] ]LME ] PHY    ]
    *----* *-------------*

 -------------------------------------------------------------------------------
 Figure 29. Information Flow - Agent Process / Managing Process
 -------------------------------------------------------------------------------

    *--------------------*                   *--------------------*
    ] Agent Process      ]     ROS(CMIP)     ]      Agent Process ]
    ]                    ] <---------------> ]                    ]
    ]    *---------------*                   *--------------*     ]
    ]    ] *-------------*                   *------------* ]     ]
    ]    ] ]LME ] LLC    ]                   ]   LLC ] LME] ]     ]
    ]    ] ]----+--------]                   ]-------+----] ]     ]
    ]    ] ]LME ] MAC    ]                   ]   MAC ] LME] ]     ]
    ]    ] ]----+--------]                   ]-------+----] ]     ]
    ]    ] ]LME ] PHY    ]                   ]   PHY ] LME] ]     ]
    *----* *-------------*                   *------------* *-----*

 -------------------------------------------------------------------------------
 Figure 30. Information Flow - Agent Process / Agent Process

 2.4.1.2  Registration
 In order to allow for the management of a station to begin, it is necessary
 for two-way communication between the managing process and the agent process
 to take place. The managing process must know that the station, and hence
 agent process, is attached to the LAN and is available to be managed. In its
 turn, the agent must know to which managing process to send events.
 These functions can be provided by a REGISTRATION PROCESS.
 NOTE:  By showing the protocol flow of this operation, it is also the intent
 to help explain the relationship between CMIP and ROS protocols.  The relevant
 figure is Figure 31 under heading "2.4.1.2  Registration".  Also, although OSI
 defines the ROS and CMIP protocols, it does not as yet define exactly what,
 for instance, an EventType and EventData might be.  Therefore, an event, such
 as function present, or register request, are implementation dependent.
 +------------------------------------------------------------------------------
 ]
 ]
 ]Station Manager. Agent                   LAN Manager. Management
 ]                 process                              process
 ]
 ]  -- the Station Manager sends a CMIP EVENT to the Functional
 ]     address of the LAN Manager to announce the process as
 ]     present
 ]
 ]  -- Note that the CMIP command (EVENT) is enveloped by the ROS INVOKE,
 ]     which is abbreviated to ROIV
 ]
 ]
 ]      ROIV(EVENT (Function Present (parameters
 ]    --------------------------------------------->
 ]
 ]
 ]  -- If that process is to be managed, then Registration will
 ]     begin
 ]
 ]  -- The managing process must find a route to the agent, if
 ]     it does not already have one. This can be obtained using
 ]     Find/Found.
 ]
 ]      FIND
 ]    <---------------------------------------------
 ]                                         FOUND
 ]    --------------------------------------------->
 ]
 ]
 ]  -- Once a route is found, the managing process will send
 ]     a Register request to the Agent. This is sent
 ]     as a CMIP ACTION, imbedded within the ROS INVOKE
 ]
 ]      ROIV(ACTION (Register Request(parameters
 ]    <---------------------------------------------
 ]
 ]
 ]  -- The Agent now responds with a ROS RESULT (RORS)
 ]     showing the results of the ACTION.
 ]
 ]
 ]      RORS(ACTION (Register Request(parameters
 ]     --------------------------------------------->
 ]
 +------------------------------------------------------------------------------
 Figure 31. The Registration Process
 The Agent Processing function is now registered with the Central Managing
 Process, until either contact is lost, or a DEREGISTER action is sent.

 2.4.2  Resource Management
 Due to the fact that the relevant standards bodies have not finished defining
 what all the various managed resources actually are, it is difficult to
 describe these resources without thinking of what could be managed, or might
 need managing in a particular environment.  In the token-ring environment, we
 can begin to think of the sorts of objects that we know exist, and thus
 provide the potential of becoming managed objects. Additionally, if they were
 to become managed objects, their usefulness to the management requirements as
 stated on page 1 could be seen.
 NOTE:  It is important to remember that these objects must be considered only
 from the architectural or conceptual point of view. By listing them here,
 there is no implication that they will ever become the chosen objects, or that
 the information about them will become visible to the management process.  It
 is also important to note that there may be other object classes not listed
 here.
 Managed objects can be conveniently divided up into a series of groups, which
 are known as OBJECT CLASSES . These classes are in fact arranged
 hierarchically from a Root, and a sample structure is shown below.
 o   Root
     -   Environment
     -   Managed System
         --  Resource Management
         --  Token-Ring Layer 2 - MAC
             o   Counter
             o   Token-Ring Layer 1
             o   Name Management
             o   LAN Layer 2 - LLC
                 -   Counter
                 -   Threshold Pair
             o   LSAP
                 -   Counter
                 -   Threshold Pair
                 -   LSAP Pair
                     --  Counter
                     --  Threshold Pair
 o   Environment

     This object class represents physical equipment, and may for instance
     contain information as to the location, machine type and serial number of
     the station.
 o   Managed System

     Represents the system as a whole.
 o   Resource Management

     Essentially this equates to a LAN Station Manager application.
 o   Token-Ring Layer 2

     Information here might include the addresses that an adapter will respond
     to,(MAC, Functional or Group); the segment (ring) number that it is
     attached to, the Upstream neighbor address as well as information on
     microcode level.

     Counters for this class might include:
     -   Lost frame errors
     -   Congestion errors
     -   Frames aborted during transmit, etc.
 o   Token-Ring Layer 1

     This would represent the physical layer of the token-ring. Included here
     could be information on which access unit lobe the adapter is connected
     to, which access unit, the speed of the ring, and the wall plug number.
 o   Name Management

     Name Management and the Find/Found process is described in "2.4.3 Name
     Management"
 o   LAN Layer 2 - LLC

     Information contained might include the number of SAPs, active and
     maximum, the number of active link stations, and the type of LLC services
     supported (Type 1,2,3).

     Useful counters might be the number of frames and bytes received and
     transmitted, or the number of timeouts that have occurred.

     A THRESHOLD  is simply a relationship between two counters, and a value
     used for comparison. Thus, if ERROR and TRAFFIC were counters, a threshold
     would be ERROR/TRAFFIC with a comparison of 0.3.  This means that if the
     ERROR to TRAFFIC Ratio exceeded 0.3, an EVENT should be indicated.
 o   LSAP

     The value of the SAP, the maximum size of the information frame supported,
     the number of link stations - all of these might be made available to the
     management process, as well as counter values for the number of
     connections made to that SAP, bytes and frames transmitted.
 o   LSAP Pair

     Information specific to particular communications would be stored here
     including values of window sizes, timers etc. Counters are similar to
     those described above for the LSAP and LLC classes.
 From the foregoing text, the reader can see that if the managed objects were
 chosen correctly, then a wealth of information could be made available to the
 management process.  Information would be available on machines, their
 locations, where they were plugged into the LAN and what their addresses were,
 as well as the current condition of the system. There would also be
 information available as to the current setting of parameters (for example,
 timers) within the system, that control its routine operation. Thus many of
 the requirements defined by OSI CONFIGURATION MANAGEMENT  would be met.
 Some of the counters, for instance the bytes and frames transmitted and
 received, might enable determination to be made, not only for some aspects of
 PERFORMANCE MANAGEMENT, but for costs, and hence, charge to be made in
 accordance with the requirement of ACCOUNTING MANAGEMENT.
 FAULT MANAGEMENT  would be enhanced beyond the operation of the physical
 medium, to include the ability to monitor for intermittent errors that are not
 easily visible on the medium. For instance, adapter congestion, badly
 formatted messages and timeouts, any of which may be impacting individual
 application response times.
 SECURITY MANAGEMENT  would also be improved, particularly in conjunction with
 a Controlled Access Unit, but even without that, the "Registration Process"
 and the knowledge that machine identities are logged would enable greater
 control of LAN access and assets.
 In this discussion, mention has been made of some objects that may need to be
 managed, or that may provide useful information to assist with the five areas
 OSI defines as requiring management.  It must be remembered that the sorts of
 objects listed above are only relevant to the token-ring, other type of LAN
 would require a different set of objects, maybe even arranged in a different
 hierarchy of classes.  The IEEE (Institute of Electrical and Electronic
 Engineers) are presently defining what these classes and objects may be. With
 the advent of FDDI (Fiber Distributed Data Interface), another set of objects
 and classes will be required, but this time developed by ANSI (American
 National Standards Institute), the body responsible for the standardization of
 that technology. It might be reasonable to expect a consistency of approach;
 it means however that it may be some time before standard solutions are
 available.

 2.4.2.1.1  Summary:  A LAN Station Manager is an application that may reside
 in any station on a LAN. It:
 o   Is an application that maps to the concept of an AGENT PROCESS as defined
     by OSI Systems Management
 o   Maintains managed objects, that themselves maybe counters and pertinent
     configuration information about LAN attachments
 o   Responds to queries regarding the above information from the central
     managing process
 o   Allows the managing process to set certain configuration and threshold
     values
 o   Allows for one or more managing processes for a single agent process
 o   Reports events to that process.
 Also, if using OSI techniques, A LAN Station Manager can provide:
 o   A standardized set of information, which enables much greater visibility
     of the functional areas described by Open Systems Management.
 o   A standardized model for gathering and controlling the information.
 o   A standardized protocol for communicating with a central management
     application.
 o   It allows the network and systems management protocols to be independent
     of the "transport pipes" through which they flow.
 All this means that the ability to provide a central LAN Management process is
 enabled, and to provide a consistent set of information from LAN-attached
 stations whatever their make or type, to the benefit of the organization
 running the LAN.
 A subset of the concept of LAN Station Manager, the agent process, is
 implemented in the:
 o   IBM LAN Station Manager Version 1.0 - see "9.5 IBM LAN Station Manager
     V1.0."
 o   IBM 8230 Controlled Access Unit - see "5.1.1.2 IBM 8230 Controlled Access
     Unit."
 The LAN Managing process is implemented by the IBM LAN Network Manager V1.0,
 IBM LAN Network Manager V1.1, and IBM LAN Network Manager Entry V1.0 - see
 "9.3.5 IBM LAN Network Manager V1."

 2.4.3  Name Management
 A Find/Found function has been implemented in IBM LAN Network Manager, IBM LAN
 Network Manager V1.1, IBM LAN Network Manager Entry V1.0 and IBM 8230
 Controlled Access Unit to simplify the process whereby the Managing process
 registers the LAN Stations and 8230's. It allows an application name to be
 registered on a workstation. Then using the Find/Found function LAN
 workstations can 'find' each other and determine a route with which to
 communicate.
 For instance, the IBM LAN Network Manager can dynamically  'find' an 8230 that
 it is responsible for and register it.

 3.0 LAN Architectures and Standards
 In the previous chapter, "2.0 LAN Technology," various technological
 approaches were described for both physical LAN attachment considerations and
 medium access methods.  Some alternative approaches to LAN interconnection
 were also introduced.
 The 802 Project of the Institute of Electrical and Electronics Engineers
 (IEEE) has produced a set of standards for LAN architectures, giving vendors
 guidance for producing LAN products and users a choice of standardized local
 area networks with a certain degree of interconnectivity.  The IEEE LAN
 standards align with the bottom two layers of the International Standards
 Organization's (ISO) model for Open Systems Interconnection, referred to as
 the OSI REFERENCE MODEL.

 3.1  LAN and Communications Standards
 The International Standards Organization (ISO) developed the seven-layer OSI
 Reference Model to provide a standard reference for intercommunication between
 computer systems through a network using common protocols.
 The ISO Reference Model, depicted in Figure 33 under heading "3.1.2  OSI and
 SNA Models", became an international standard in 1983 (IS 7498).  Each layer
 addresses a well-defined section of the total architecture.  The Layers of the
 OSI Reference Model are, from top to bottom:
 o   Application Layer

     The application layer gives the user access to all the lower OSI
     functions.  The purpose of this layer is to support semantic exchanges
     between applications existing in "open" systems.
 o   Presentation Layer

     The presentation layer is concerned with the representation of user or
     system data.  This includes necessary conversions (for example, printer
     control characters) and code translation (for example, ASCII to or from
     EBCDIC).
 o   Session Layer

     The session layer provides mechanisms for organizing and structuring
     interaction between applications and/or devices.
 o   Transport Layer

     The transport layer provides transparent and reliable end-to-end data
     transfer, relying on lower layer functions for handling the peculiarities
     of the actual transfer medium.
 o   Network Layer

     The network layer provides the means to establish connections between
     networks.  The standard also includes procedures for the operational
     control of inter-network communications and for the routing of information
     through multiple networks.
 o   Data Link Layer

     The data link layer provides the functions and protocols to transfer data
     between network entities and to detect (and possibly correct) errors that
     may occur in the physical layer.
 o   Physical Layer

     The physical layer is responsible for physically transmitting the data
     over the communications link.  It provides the mechanical, electrical,
     functional and procedural standards to access the physical medium.
 This layered approach was selected as a basis for the OSI Reference Model to
 provide flexibility and open-ended capability through defined interfaces. The
 interfaces permit some layers to be changed while leaving other layers
 unchanged.  In principle, as long as standard interfaces to the adjacent
 layers are adhered to, an implementation can still work.  For example, a
 system implementation could use either HDLC or local area network protocols as
 the data link layer.  Similarly, a particular layer such as the presentation
 layer, can be implemented as a null layer for the time being. This means the
 layer is functionally empty, providing only the mandatory interfaces between
 the upper and lower layers (application and session layers respectively).  The
 Manufacturing Automation Protocols (MAP 2.1) "3.2.1.2 IEEE 802.4, ISO 8802-4")
 exemplify implementation with a null layer.

 3.1.1  IEEE 802 and OSI
 In February 1980, The Institute of Electrical and Electronic Engineers' (IEEE)
 Computer Society established "Project 802" to draft standards for local area
 networks. In keeping with the OSI approach, IEEE Project 802 created a
 reference model with two layers (which correspond to the data link and
 physical layers of the OSI model).  In the IEEE model, however, the data link
 layer is further divided into two sublayers: the LOGICAL LINK CONTROL (LLC)
 sublayer,  and the MEDIUM ACCESS CONTROL (MAC) sublayer.
 Details on these sublayers can be found in "3.2 LAN Standards."
 Due to the variety of technically sound approaches proposed for local area
 networks, IEEE Project 802 decided to draft standards for the most probable
 implementations:

 o   CSMA/CD (Contention Bus)
 o   Token-passing bus
 o   Token-passing ring.
 The commonly used names for these standards are derived from the project's
 initial designation "802". Hence, we have:

 o   IEEE 802.1 - Higher level interface standard
 o   IEEE 802.2 - Logical link control standard
 o   IEEE 802.3 - CSMA/CD standard
 o   IEEE 802.4 - Token-passing bus standard
 o   IEEE 802.5 - Token-passing ring standard.
 Over the years, the IEEE work has expanded, with the formation of new
 subcommittees. These include:
 o   IEEE 802.6 - Metropolitan Area Networks (MANs)
 o   IEEE 802.7 - Broadband Technical Advisory Group
 o   IEEE 802.8 - Fiber Technical Advisory Group
 o   IEEE 802.9 - Integrated Voice/Data on LAN
 o   IEEE 802.10 - Interoperable LAN Security
 o   IEEE 802.11 - Wire-less LANs.
 The IEEE 802.1 Higher Level Interface subcommittee is currently finalizing the
 draft IEEE 802.1 standard, also presented to the ISO as an ISO draft proposal.
 This draft includes the following subjects:
 o   IEEE 802.1 Part A which describes the relationship of the IEEE 802 work to
     the ISO Open Systems Interconnection Basic Reference Model.
 o   IEEE 802.1 Part B which specifies an architecture and protocol for the
     management of IEEE 802 LANs.
 o   IEEE 802.1 Part D which specifies an architecture and protocol for the
     interconnection of IEEE 802 LANs below the MAC service boundary.
 o   IEEE 802.1 Part E which deals with a Station Load Protocol, used for IPL
     of workstations from a server.
 o   IEEE 802.1 Part F which addresses guidelines for the development of layer
     management standards and definition of managed objects.
 Figure 32 under heading "3.1.1  IEEE 802 and OSI" depicts the relationship
 between the IEEE 802.x projects and standards.

 +------------------------------------------------------------------------------
 ]
 ]
 ]  To Layer
 ]     A 7
 ]     ]
 ]]    ]   ]  *-----------------------------------------------------------------
 ]]        ]  ]
 ]]  IEEE  ]  ]                           IEEE 802.1
 ]] 802.10 ]  ]            Higher-Level Interface and Interworking
 ]] Inter- ]  ]
 ]]Operable]  ]    *------------------------------------------------------------
 ]]  LAN   ]  ]    ]*-----------------------------------------------------------
 ]]Security]  ]    ]]
 ]]        ]  ]    ]]
 ]]        ]  ]    ]]                        IEEE 802.2
 ]]        ]  ]    ]]                   Logical Link Control
 ]]        ]  ]    ]]
 ]]        ]  ]    ]]
 ]*--------*  ]    ]*-----------------------------------------------------------
 ]            ]    ]*----------* *----------* *----------* *----------* *-------
 ]            ]    ]]IEEE 802.3] ]IEEE 802.4] ]IEEE 802.5] ]IEEE 802.6] ]IEEE 80
 ]            ]    ]] CSMA/CD  ] ]Token Bus ] ]Token-Ring] ]          ] ]
 ]            ]    ]]  Medium  ] ]  Medium  ] ]  Medium  ] ]          ] ]
 ]            ]    ]]  Access  ] ]  Access  ] ]  Access  ] ]  Metro-  ] ]Integra
 ]            ]    ]]----------] ]----------] ]----------] ]  politan ] ] Voice
 ]            ]    ]]          ] ]          ] ]Token-Ring] ]   Area   ] ] Data
 ]            ]    ]] CSMA/CD  ] ]Token Bus ] ]  Media   ] ]          ] ]
 ]            ]    ]]  Media   ] ]  Media   ] ]IBM Cablng] ]          ] ]
 ]            ]    ]]          ] ]          ] ]  System  ] ]          ] ]
 ]            *----**----------* *----------* *----------* *----------* *-------
 ]
 ]
 ]                         *------------------*       *------------------*
 ]                         ]    IEEE 802.7    ]       ]    IEEE 802.8    ]
 ]                         ]     Broadband    ]       ]    Fiber Optic   ]
 ]                         ] Tech. Adv. Group ]       ] Tech. Adv. Group ]
 ]                         *------------------*       *------------------*
 ]
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 32. Relationships Among the 802 Standards
 The International Standards Organization has since adopted the IEEE 802
 standards as part of the OSI Reference Model, and has given them the following
 ISO numbers:

 o   IEEE 802.2  Currently an OSI International Standard, IS 8802-2 dated 1989
 o   IEEE 802.3  Currently an OSI International Standard, IS 8802-3 dated 1989
 o   IEEE 802.4  Currently an OSI International Standard, IS 8802-4 currently
     unpublished
 o   IEEE 802.5  Currently an OSI International Standard, IS 8802-5.  currently
     unpublished
 Before publishing 8802-5, ISO was waiting for the result of balloting on four
 Proposed Draft Addenda (PDADs) to the standard.  These were:
 o   PDAD 1 - Token ring operation at 16Mbps
 o   PDAD 2 - MAC sublayer enhancements
 o   PDAD 3 - Station management entity specification
 o   PDAD 4 - Source routing.
 As of this time, PDADs 1, 2, and 3 have all progressed within ISO to Draft
 Addenda, which will be lumped together with 8802-5, and a new Draft
 International Standard DIS 8802-5.2 will be voted on and then published.
 PDAD 4 on Source Routing has recently and dramatically changed shape.  Due to
 the advent of the Source Routing Transparent (SRT) Bridge, described in "6.3.3
 Source Routing/Transparent Bridging Inter-operability," the addendum will now
 only contain details of token-ring frame formats including the Routing
 Information field.  All the rest of the work has moved into IEEE 802.1 Part D.
 It is hoped that the balloting on PDAD 4 will be finished in time to be
 incorporated in the DIS ballot for 8802-5.2.

 3.1.2  OSI and SNA Models
 IBM System Network Architecture (SNA) is a proprietary layered architecture
 which, although defined earlier than the OSI Reference Model, is based upon a
 seven-layer structure.  SNA was announced as IBM's networking architecture in
 1974, and the first products implementing the SNA protocols became available
 in the mid 1970s.  Since then, SNA has continued to grow and evolve. Part of
 this evolution has included IBM's support of standard communications
 interfaces through continued publication and update of SNA specifications, and
 through development of enhancements to SNA closely coordinated with emerging
 international standards.  In this way IBM developed the IBM Token-Ring Network
 as an enhancement to SNA while participating actively in the development of
 the IEEE 802.5 and 802.2 standards.
 Figure 33 under heading "3.1.2  OSI and SNA Models" shows a comparison of the
 OSI, IEEE 802 and the SNA models.
 +------------------------------------------------------------------------------
 ]
 ]
 ]           OSI                                                     SNA
 ]          Model                                                   Layers
 ]      *------------*                                        *-----------------
 ]      ]Application ]                                        ]   Transaction
 ]      ]------------]                                        ]-----------------
 ]      ]Presentation]                                        ]  Presentation
 ]      ]------------]                                        ]-----------------
 ]      ]  Session   ]                                        ]Data Flow Control
 ]      ]------------]                                        ]-----------------
 ]      ] Transport  ]                                        ]Transmission Ctrl
 ]      ]------------]                                        ]-----------------
 ]      ]  Network   ]                 IEEE 802 Model         ]  Path Control
 ]      ]------------]         *----------------------------* ]-----------------
 ]      ]    Data    ]    *--> ]Logical Link Control]       ] ]      Data
 ]      ]            ] <--]    ]--------------------]Station] ]      Link
 ]      ]    Link    ]    *--> ]Medium Access Ctrl  ]       ] ]     Control
 ]      ]------------]         ]--------------------] Mgt.  ] ]-----------------
 ]      ]  Physical  ] <-----> ]  Physical Control  ]       ] ]    Physical
 ]      *------------*         *----------------------------* *-----------------
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 33. OSI Reference Model, IEEE 802 Local Area Network Model, and SNA Mode
 Although there is general correspondence between the OSI and the SNA layers,
 the detailed protocols and services vary.  The SNA layers (from the top down)
 are:
 o   Transaction services

     The transaction services layer provides application services to the end
     user of an SNA network.  These services are also used by IBM Office
     Architectures: Document Interchange Architecture (DIA) for document
     distribution between office systems, and SNA Distribution Services (SNADS)
     for asynchronous data distribution between distributed applications and
     office systems.

     The transaction services layer also provides configuration, session and
     management services to control network operation.
 o   Presentation services

     The presentation services layer is concerned with the representation of
     application,  end-user,  and system data.  The services provided include
     3270 data stream support and intelligent printer data stream support.

     The presentation services layer also defines protocols for
     program-to-program communication,  and controls conversation-level
     communication between transaction programs.
 o   Data flow control

     The data flow control layer provides flow control services for logical
     unit to logical unit (LU-LU) sessions.  It does this by assigning sequence
     numbers, correlating requests and responses, enforcing session request and
     response mode protocols and coordinating session send and receive modes.
 o   Transmission control

     The transmission control layer provides basic control of the transmission
     resources in the network, verifying received sequence numbers, and
     managing session level pacing.  Boundary function support for peripheral
     nodes is provided by transmission control, and data encryption can also be
     supported by this layer's services.
 o   Path control

     The path control layer provides protocols to route message units through
     an SNA network,  and to interconnected SNA networks (via System Network
     Interconnect - SNI).
 o   Data link control

     The data link control layer provides protocols for transferring message
     units across the physical link between two nodes,  and also provides
     link-level flow control and error recovery.  The data link control layer
     supports SDLC,  System/370 data channel, X.25 and IEEE 802.2 and 802.5
     protocols.
 o   Physical control

     The physical control layer provides a physical interface for any
     transmission medium attached to it. This layer defines the signaling
     characteristics needed to establish,  maintain,  and terminate physical
     connections for supported attachments.

 3.2  LAN Standards
 The data link layer provides the protocols used to physically transmit data on
 a communications link. These protocols must be able to detect when a
 transmission has been corrupted by errors and to retransmit the data.
 The IEEE 802 project divided the data link layer into two sublayers, the
 MEDIUM ACCESS CONTROL (MAC) layer and the LOGICAL LINK CONTROL (LLC) layer.
 These sublayers are discussed in the following sections.
 Today, there is a growing requirement to further divide the physical layer
 into a PHYSICAL and a PHYSICAL MEDIUM DEPENDENT layer.  This approach was seen
 in the discussion on FDDI. See "2.3 Fiber Distributed Data Interface
 Concepts."
 As previously mentioned, the IEEE 802.1 subcommittee work has not yet been
 completed, especially in the areas of the management and interconnection of
 IEEE 802 LANs.

 3.2.1  Physical Layer and MAC Sublayer
 The medium access control (MAC) sublayer contains mechanisms to control
 transmissions on the LAN so that two or more stations don't try to transmit
 data at the same time, logic to control whether a station on the LAN is in
 transmit, repeat, or receive state, and addressing schemes to control the
 routing of data on the LAN.  It also provides some or all of the following
 functions:
 o   MAC addressing.  A MAC address is the physical address of the station
     (that is, device adapter) on the LAN,  a pre-defined group address which
     is recognized by adapters of devices belonging to the group, a broadcast
     address which is recognized by all adapters on the LAN or a null address
     for frames which should not be received by any station on the LAN.  The
     MAC address is used to identify the physical destination and source of
     anything transmitted on the LAN.
 o   Frame copying.  This is the "receipt", that is, copying of a frame into
     the buffers of an attached adapter which recognizes its own address in the
     destination address field of a frame.
 o   Frame type recognition.  This is the identification of the type (for
     example, system or user) and format of a frame of data.
 o   Frame control.  This function ensures that frames can be processed
     accurately by providing frame check sequence numbers and starting or
     ending frame delimiters.
 o   Priority management.  This function allows preferential access to the
     medium while maintaining fairness with respect to all participating
     stations.
 o   LAN management.  A collection of protocols has been defined to support
     monitoring of a LAN and the ability to handle error conditions at the
     access control level.
 Some access protocols do not provide priority management or frame control
 functions, but rely on higher layer services to provide these functions.

 3.2.1.1  IEEE 802.3, IS 8802-3
 The IEEE 802.3 standard describes the access method and the physical layer
 specifications for a contention bus LAN.  The standard specifies a
 1-persistent carrier sense multiple access with collision detection (CSMA/CD)
 access protocol, using baseband transmission on a single channel pair at
 10Mbps. Binary data is transmitted as signal elements on a common shielded 50
 Ohm coax cable using the Manchester code scheme.  Baseband bus is the most
 popular IEEE 802.3 topology, although a star-wired baseband bus and broadband
 tree are also part of the standard.
 The maximum allowable non-repeated distance between stations is a 500-meter
 segment. One or more segments may attach to a particular segment using
 repeaters. However the maximum number of segments in any end-to-end path is
 five, that is, a maximum of four repeaters in any path.  Within any path, no
 more than three segments may have stations attached to them, while the maximum
 number of attachments to one segment is 100.
 For the total LAN, 1024 attachments are allowed, with a total end-to-end
 distance between stations not exceeding 2.5 kilometers.
 The standard also describes the TRANSCEIVER UNIT, used to couple the Data
 Terminal Equipment (DTE) to the medium. The transceiver unit components
 together with the associated medium attachment taps cause signal reflections
 and standing waves (second and third harmonic distortion) due to bridging
 impedances whenever a transmission occurs.  The unusual 50 Ohm coaxial cable
 was selected to limit the capacitance caused by the taps.  Because of these
 reflections and standing waves, the placement of transceivers along the cable
 and the lengths of the cables themselves must be controlled to ensure that
 transmissions are not disrupted.  For example, if the standing waves set up by
 one station's transmission were strong enough, they could be mistaken by that
 transmitting station for another transmitting station; that is, the
 transmitting station would erroneously detect a collision.  Station attachment
 to the common bus must be separated by multiples of 2.5 meters to prevent
 reflections caused by the taps from adding up in phase.
 IS 8802-3 contains standards for several different implementations of CSMA/CD
 LANs. These include:
 o   10base5 - 10Mbps, baseband, maximum bus length of a segment is 500 meters
 o   10base2 - 10Mbps, baseband, maximum bus length of a segment is 200 meters.
 Additional work is progressing on:
 o   10broad36 - an IEEE standard for a 10Mbps, broadband network, but not yet
     included in ISO
 o   10baseT - CSMA/CD LAN on Telephone Twisted Pair wiring
 o   10baseF - a CSMA/CD implementation on Optical Fiber.
 An early IEEE standard, 1base5, implemented commercially as Starlan(**) was
 not incorporated into 8802-3.

 3.2.1.1.1  Service Primitives:  The basic MAC service primitives used in this
 and all IEEE MAC standards are:
 o   Medium access data request (MA_DATA.request)

     This primitive is generated whenever the LLC sublayer has data to be
     transmitted to another station(s) on the LAN. The MAC sublayer formats it
     in a MAC frame and transmits it.
 o   Medium access data confirm (MA_DATA.confirm)

     This primitive is generated by the MAC sublayer in response to a
     "MA_DATA.request" from the local LLC sublayer. A status parameter is used
     to indicate the outcome of the associated MA_DATA.request.
 o   Medium access data indicate (MA_DATA.indicate)

     This primitive is sent to indicate that a valid frame arrived at the local
     MAC layer. The frame was transmitted without errors and was correctly
     addressed.
 o   Medium access data response (MA_DATA.response)

     This primitive is used as a response to a MA_DATA.indicate.
 One use of these primitives is shown in Figure 34 under heading "3.2.1.1.1
 Service Primitives".  The figure shows two stations, A and B, with the LLC
 layer of station A requesting transmission of a frame to the MAC service
 interface. Upon receipt of the frame by station B, an indicate is generated,
 notifying the LLC of an incoming frame. LLC generates response to indicate
 that it has the frame. The confirm indicates to station A that the frame was
 transmitted without error.
 +------------------------------------------------------------------------------
 ]
 ]        Station A                    Station B
 ]                    MAC         MAC
 ]             Service I/F   Service I/F
 ]                     ]           ]
 ]                     ]           ]
 ]    MA_DATA.request  ]           ]
 ]    ---------------->]           ]
 ]                     ]           ]MA_DATA.indicate
 ]                     ]           ]--------------->
 ]                     ]           ]
 ]                     ]    LAN    ]
 ]                     ]           ]MA_DATA.response
 ]                     ]           ]<---------------
 ]                     ]           ]
 ]    MA_DATA.confirm  ]           ]
 ]    <----------------]           ]
 ]                     ]           ]
 +------------------------------------------------------------------------------
 Figure 34. IEEE MAC Primitives
 The CSMA/CD medium access protocol was described in "2.2.1 Basic CSMA/CD
 Concepts." Figure 9 under heading "2.2.1.1.1  Frame Format" shows the
 eight-field structure of the 802.3 standard MAC frame.

 3.2.1.1.2  Summary:  The IEEE 802.3 standard is a contention-based protocol.
 For low traffic volumes and relatively short messages, an IEEE 802.3 LAN can
 provide the best response time.  However, because of the instability
 introduced by collision recovery during periods of high utilization, response
 times and performance cannot be predicted reliably.  At the MAC level, the
 IEEE 802.3 protocol cannot guarantee access to the medium.  These performance
 considerations make IEEE 802.3 protocol LANs less desirable than other
 protocols for backbone LANs.
 All stations have equal rights to transmit on an idle bus.  In low-traffic
 situations, this minimizes the need to handle priority requests.  However,
 with heavier traffic, the lack of priority support within the protocol may be
 a problem for some applications.
 Special considerations may be required for applications or data with security
 requirements, because IEEE 802.3 stations broadcast their frames
 simultaneously to all other LAN stations on the network which therefore can
 receive and copy any transmitted data.
 Network management is not defined within the IEEE 802.3 standard. It is under
 consideration as part of the IEEE 802.1 sub-project (see "3.1.1 IEEE 802 and
 OSI").

 3.2.1.2  IEEE 802.4, ISO 8802-4
 The IEEE 802.4 standard describes the token-passing bus access protocol and
 its physical layer specifications.  In this type of LAN, stations on the
 network are physically connected to a bus, but access to the bus is controlled
 as if it were a logical ring.  Each station keeps track of the addresses of
 its logical neighbors (that is, those which immediately precede and follow it
 in a logical sequence).  The physical connection sequence on the bus is
 independent from the order of the logical ring.
 A token is used to control access to the bus.  Once a station has control of a
 token, it has complete control of the bus for a defined period of time (the
 token_holding time).  In addition to transmitting one or more frames, the
 controlling station can poll other stations and receive responses or
 acknowledgements during this time period. When it wishes to relinquish control
 of the bus or when the token_holding timer expires, the station passes the
 token on to its successor station.
 The IEEE 802.4 standard defines broadband transmission on shielded coax cable
 at data rates of 1, 5 or 10 Mbps.  It provides a choice of different
 modulation techniques and cable types.  There are three standard topologies,
 each involving different modulation techniques and cable types used for the
 trunk and drops.  The three topologies have the following characteristics:
 o   Omni-directional bus at 1 Mbps, using Manchester encoding.
 o   Omni-directional bus at 5 or 10 Mbps.
 o   Directional bus with active head-end repeater at 1, 5 or 10 Mbps.
 The token-passing bus medium access protocol was described earlier in "2.2.3
 Basic Token-Passing Bus Concepts."
 In summary, one or more stations on the bus must perform the following
 functions:
 o   RING INITIALIZATION, performed when the network is first powered up and
     after a catastrophic error.
 o   STATION ADDITION, optionally performed when a station holding the token
     accepts the insertion of a new successor station (that is, a new station
     with an address that is between that of the station holding the token and
     its current successor station.
 o   STATION REMOVAL, achieved by sending a new successor identification to its
     predecessor, or by just disconnecting from the LAN.  In the latter case,
     recovery mechanisms will establish the proper new logical ring
     configuration.
 o   RECOVERY AND MANAGEMENT, including recovery from the following types of
     failures:
     -   Bus idle (lack of activity on the bus).
     -   Token-passing failure (lack of valid frame transmission).
     -   Duplicate token (detected by the token-holding station).
     -   Detection of a station with a faulty receiver.
     -   Duplicate MAC addresses.
 Figure 21 under heading "2.2.3.1.1  Frame Format" shows the generic 802.4
 standard MAC frame format as well as the IEEE 802.4 token format which is
 transmitted as a special frame.

 3.2.1.2.1  IBM and IEEE 802.4 - ISO IS 8802-4:  In 1984, IBM issued a
 statement of direction stating IBM's intention to implement the Manufacturing
 Automation Protocol (MAP) standard based upon approval of the MAP Version 3
 specifications.  IBM also refers to MAP as the INDUSTRIAL LAN, which is part
 of the IBM COMPUTER-INTEGRATED MANUFACTURING (CIM) product offerings.  The
 ultimate goal of CIM is integration of all processes involved in a
 manufacturing environment. Integration is based on controlling the information
 flow for which MAP as a full seven-layer communications architecture will
 provide networking and applications support.  The ISO 8802-4 standard provides
 the two lowest layers of this seven-layer architecture.

 3.2.1.2.2  Manufacturing Automation Protocol:  Work on a MAP standard started
 in 1980 as a task force within the General Motors Corporation.  Gradually
 other manufacturers, including IBM, began to participate in the definition of
 the protocols and the implementation of products.
 The following milestones have occurred in the development of the MAP standard:
 o   MAP 1.0 was released in April 1984 as the result of the General Motors
     task force.
 o   Based upon the participation of additional companies in the
     standardization process, MAP 2.1 was issued in March 1985 as a set of
     interim specifications to allow early product development and experience.
 o   In December 1985, MAP 2.1 was updated to correct some mistakes in the
     earlier release.
 o   MAP 2.2 was released in March 1987, with the addition of carrierband
     network specifications.
 o   The ultimate standard, referred to as MAP 3.0, was released as a draft in
     April 1987.  Final release occurred in 1988.
 Figure 35 under heading "3.2.1.2.2  Manufacturing Automation Protocol" shows
 the relationship between the seven-layer OSI Reference Model and MAP 2.1.
 +------------------------------------------------------------------------------
 ]
 ]
 ]             OSI Layers                  MAP 2.1
 ]
 ]           *---------------------------*
 ]           ]                           ] MMFS/EIA 1393A
 ]           ] 7 Application             ] ISO CASE Kernel
 ]           ]                           ] ISO FTAM Subset
 ]           ]                           ] Directory Services Subset
 ]           ]---------------------------]
 ]           ] 6 Presentation            ] null layer
 ]           ]                           ]
 ]           ]---------------------------]
 ]           ] 5 Session                 ] ISO Session Kernel 8327
 ]           ]                           ]
 ]           ]---------------------------]
 ]           ] 4 Transport               ] ISO Transport (Class 4) 8073
 ]           ]                           ]
 ]           ]---------------------------]
 ]           ] 3 Network                 ] ISO Connectionless Internet
 ]           ]                           ]     Protocol 8473
 ]           ]---------------------------]
 ]           ] 2 Data ] Logical Link Ctl ] ISO 8802-2 Link Level (Class I)
 ]           ]        ] - - - - - - - - -]
 ]           ]   link ] medium access ctl]            Token-passing bus
 ]           ]---------------------------] ISO 8802-4
 ]           ] 1 Physical                ]            Broadband Media
 ]           ]                           ]
 ]           *---------------------------*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 35. MAP 2.1 and the OSI Reference Model
 MAP 2.1 specifications have been subject to two main criticisms:
 1.  When multi-channel capability is not required, the full broadband
     implementation is excessively expensive and not required. Therefore some
     potential users and vendors preferred a carrierband LAN implementation.
 2.  The processing of a full seven-layer implementation of the architecture
     may require too much processing time for smaller systems in time-critical
     applications. Initially, this critique was addressed by two different
     approaches, MAP/ENHANCED PERFORMANCE ARCHITECTURE (MAP/EPA) and MINIMAP
     (see Figure 36 under heading "3.2.1.2.2  Manufacturing Automation
     Protocol").
 +------------------------------------------------------------------------------
 ]
 ]
 ]          MAP/Enhanced Performance
 ]              Architecture
 ]
 ]      *--------*       *-------------*
 ]      ]MAP/OSI ]       ]Time-Critical]
 ]      ]Applic. ]<----->] Application ]<--*
 ]      *--------*       *-------------*   ]
 ]              ]         ]                ]          MiniMAP
 ]          *------------------*           ]
 ]          ]   7    ]    I    ]           ]    *------------------*
 ]          ]--------]    n    ]           ]    ]   Time-Critical  ]
 ]          ]   6    ]    t    ]           *--->]    Application   ]
 ]          ]--------]    e    ]                *------------------*
 ]          ]   5    ]    r    ]                          ]
 ]          ]--------]    f    ]                *------------------*
 ]          ]   4    ]    a    ]                ]     Interface    ]
 ]          ]--------]    c    ]                *------------------*
 ]          ]   3    ]    e    ]                          ]
 ]          ]------------------]                *------------------*
 ]          ]     ]   LLC      ]                ]     ]   LLC      ]
 ]          ]   2 ] - - - - - -]                ]   2 ] - - - - - -]
 ]          ]     ]   MAC      ]                ]     ]   MAC      ]
 ]          ]------------------]                ]------------------]
 ]          ]   1  Physical    ]                ]   1  Physical    ]
 ]          *------------------*                *------------------*
 ]                   ]                                   ]
 ]                   ]                                   ]
 ]          -------------------                 -------------------
 ]             Physical Media                      Physical Media
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 36. MAP/EPA and MiniMAP
 MAP Version 3 enhances MAP 2.1 by:
 o   Imbedding the MAP/EPA and MiniMAP approaches into the standard to meet the
     time-dependent requirements of the process industry.
 o   Replacing MMFS by the Manufacturing Messaging Specifications (MMS).
 o   Including OSI presentation layer 6 support.
 o   Extending layer 4 class 4 service dealing with error detection and
     recovery.
 With respect to network interconnection, the MAP approach is to provide a
 full, seven-layer MAP 3.0 backbone configuration at the plant floor
 interconnected with other carrierband MAP LANs and other standard LANs such as
 as IEEE 802.3 and IEEE 802.5.  This approach addresses the objective to
 integrate technical design, office and business applications, computer-aided
 production management and manufacturing with the communications requirements
 of the individual production cells as shown in a sample configuration in
 Figure 37 under heading "3.2.1.2.2  Manufacturing Automation Protocol".
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                                 *------------ Technical Design
 ]                                 ]
 ]                        *------------------*
 ]     X.25<---*   *---*  ]                  ]-- Office appl.
 ]             *---]G/W]--]  Token-Ring LAN  ]
 ]     Info.<---*  *------]                  ]-- Business appl.
 ]     Provider *---]G/W] *------------------*
 ]                  *---*          ]
 ]                             *-------*
 ]                             ]Bridge/]
 ]                             ]Router ]
 ]                             *-------*
 ]                                 ]
 ]         Computer-Aided Production Management and Manufacture
 ]            Full MAP             ]        Other 8802-2 LAN
 ]        *---* *---* *---*        ]        *---* *---* *---*
 ]        *---* *---* *---*        ]        *---* *---* *---*
 ]          *-----+-----*          ]          *-----+-----*
 ]            *-------*            ]            *-------*
 ]            ]Router ]            ]            ]Bridge ]
 ]            *-------*            ]            *-------*
 ]     <-------------------------------------------------------------> Full MAP
 ]     <-------------------------------------------------------------> Broadband
 ]                                 ]                      *---*        backbone
 ]                             *-------*                  ]G/W]
 ]                             ]Bridge/]                  *---*
 ]                             ]Router ]                    ]
 ]                             *-------*                    **
 ]                                 ]                         ]
 ]                                 ]                     X.25 to remote sites
 ]             inter- and intra-cell communications
 ]     <-------------------------------------------------------------> Baseband
 ]     <-------------------------------------------------------------> MAP
 ]            *-------*                         *-------*
 ]            ]Gateway]                         ]MAP/EPA]
 ]            *-------*                         *-------*
 ]          *-----+-----*                     *-----+-----*
 ]        *---* *---* *---* Production      *---* *---* *---* Production
 ]        *---* *---* *---* cell            *---* *---* *---* cell
 ]         Proprietary N/W                       MiniMAP
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 37. MAP Integrated Network Configuration
 An important concern which appeared during the evolution of the Manufacturing
 Automation Protocol is associated with migration from MAP 2.1 local area
 networks to a MAP 3.0 environment.  This may be difficult because of the
 nature of the changes.  Additional information is provided in "5.4.1 The 8232
 LAN Channel Station and Industrial LAN."

 3.2.1.2.3  Summary:  The token-passing bus access method is predominately used
 for industrial LANs. It uses a logical ring on a physical bus, and has a
 number of transmission techniques and data rates to choose from.
 The protocol optionally provides eight priority service classes to higher
 level data frames, handled at the MAC level by four access classes based upon
 the current traffic load on the bus.
 With respect to a full seven-layer architecture for the manufacturing
 environment, application implementation is very limited because of the
 immaturity of the standards, but will likely increase as the standards are
 finalized.

 3.2.1.3  IEEE 802.5, ISO IS 8802-5
 The IEEE 802.5 standard describes the token-passing ring medium access
 protocol and its physical attachments.
 In a token-passing ring network the stations on the LAN are physically
 connected to a wiring concentrator usually in a star-wired ring topology.
 Logically, stations are connected in a pure ring topology.  Each station has
 driver/transmitter as well as receiver circuitry (see Figure 38 under heading
 "3.2.1.3  IEEE 802.5, ISO IS 8802-5").
 Differential Manchester code is used to convert binary data into signal
 elements, which are transmitted at 1 or 4 Mbps IEEE standard speeds.   An
 update to the standards to support 16 Mbps is currently in the process of
 review and approval.  The standard does not prescribe the type of cabling to
 be used.  In IBM's Token-Ring Network implementation, shielded twisted pair
 cabling is recommended.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                        *-----*       *-----*
 ]                        ] S2  ]       ] S3  ]
 ]                        ]-----]       ]-----]
 ]                  *-----]R ] D]-------]R ] D]-----*
 ]                  ]     *-----*       *-----*     ]
 ]              *----*  *--------->                *----*
 ]              ]  ]D]  ]     Token                ]R]  ]
 ]              ]S1]-]  ]                          ]-]S4]
 ]              ]  ]R]  ]                          ]D]  ]
 ]              *----*  *---                       *----*
 ]                  ]     *-----*       *-----*     ]
 ]                  *-----]D ] R]-------]D ] R]-----*
 ]                        ]-----]       ]-----]
 ]                        ] S6  ]       ] S5  ]
 ]                        *-----*       *-----*
 ]
 ]
 ]                 D = driver/transmitter
 ]                 R = Receiver
 ]                 S1 to S6 are ring stations
 ]
 +------------------------------------------------------------------------------
 Figure 38. Sample Ring Configuration
 Access to the ring is controlled by a circulating token.  A station with data
 to transmit waits for a free token to arrive. When a token arrives, the
 station changes the token into a frame, appends data to it and transmits the
 frame. If the destination station is active, it will copy the frame and set
 the "frame copied" and "address recognized" bits, providing MAC level
 acknowledgement to the transmitting station.  The sending station must strip
 the frame from the ring and release a new token onto the ring.
 An option in the architecture allows the sending station to release a token
 immediately after transmitting the frame trailer, whether or not the frame
 header information has already returned.  This is called EARLY_TOKEN RELEASE
 and tends to reduce the amount of idle time in higher speed token-passing
 rings running at, for example, 16 Mbps.
 The token-passing protocol provides an extensive set of inherent fault
 isolation and error recovery function, for implementation in every attaching
 device. The adapter network management functions include:
 o   Power-on and ring insertion diagnostics.
 o   Lobe-insertion testing and online lobe fault detection.
 o   Signal loss detection, beacon support for automatic test and removal.
 o   Active and standby monitor functions.
 o   Ring transmission errors detection and reporting.
 o   Failing components isolation for automatic or manual recovery.
 The token-passing ring medium access protocol was described earlier in greater
 detail (see "2.2.2 Basic Token-Passing Ring Concepts").
 In summary, the token-passing ring protocol is based on the following
 cornerstones:
 o   ACTIVE MONITOR
     -   Ensures proper ring delay.
     -   Triggers Neighbor_Notification.
     -   Monitors token and frame transmission.
     -   Detects lost tokens and frames.
     -   Purges circulating tokens or frames from the ring.
     -   Performs auto-removal in case of multiple active monitors.
 o   STANDBY MONITOR (any other ring station)

     Detects failures in the active monitor and disruptions on the ring.
 o   TOKEN_CLAIMING PROCESS

     By which a new active monitor is elected when the current active monitor
     fails. This process may be initiated by the current active monitor or by a
     standby monitor.
 Figure 16 under heading "2.2.2.1.1  Data Transmission" shows the format of a
 802.5 standard MAC frame as well as the token format and the format of the
 abort delimiter.
 The architecture describes 28 different MAC control frames, each identified by
 a unique Major Vector Identifier (MVID). The main ones have been described in
 "2.2.2 Basic Token-Passing Ring Concepts" and are referred to as:

 o   Active Monitor Present MAC frame.
 o   Ring Purge MAC frame.
 o   Standby Monitor Present MAC frame.
 o   Claim Token MAC frame.
 o   Lobe Media Test MAC frame.
 o   Duplicate Address Test MAC frame.
 o   Request Initialization MAC frame.
 o   Beacon MAC frame.
 o   Soft Error Report MAC frame.

 3.2.1.3.1  Summary:  The token-passing protocol provides for efficient use of
 the media under both light and heavy traffic loads. It guarantees fair access
 to all participating stations. This fairness is enhanced by an eight-level
 priority mechanism, based on priority reservations made in a passing token or
 frame.  A key benefit of the token-passing ring protocol is its ability to
 handle increased traffic loads or peaks, making it an ideal protocol for
 larger and/or more heavily used LANs (including backbone rings).  This also
 makes it a good base LAN for connection to even higher bandwidth LANs such as
 FDDI.

 3.2.1.4  Fiber Distributed Data Interface
 The AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI) standards working group
 X3T9.5 has formulated a draft proposal for an international standard called
 FIBER DISTRIBUTED DATA INTERFACE (FDDI).
 A detailed description of the FDDI LAN was given in "2.3 Fiber Distributed
 Data Interface Concepts."
 In terms of current standards, FDDI is described by ISO 9314, which is
 subdivided into 6 parts.  These are:
 o   9314-1 - the physical layer
 o   9314-2 - the MAC layer
 o   9314-3 - the physical medium dependent layer
 o   9314-4 - use of FDDI on single-mode fiber
 o   9314-5 - Hybrid Ring Control - FDDI II, which divides the FDDI frame into
     slots, such that frames may contain both synchronous and asynchronous
     data. This implementation is more suitable for voice traffic.
 o   Station Management has as yet not been allocated a 9314 number.
 At this time, not all of these are International Standards. Further
 information can be found in "2.3.1.2 FDDI Standards."

 3.2.2  Logical Link Control Sublayer
 The IEEE 802.2 standard describes the top sublayer of the data link layer. It
 is common to all the MAC sublayers layers defined by the IEEE. See Figure 32
 under heading "3.1.1  IEEE 802 and OSI". This means higher layer protocols are
 shielded from the peculiarities of the physical medium as well as from the
 specific medium access protocol being used. Obviously, limitations such as
 throughput characteristics and number of attachments, inherent in each of the
 lower level standard protocols, apply equally to higher layer protocols.
 Local area networks (as well as wide area networks) need the function of a DLC
 layer to optimize the capacity, accuracy, and availability of the physical
 medium.
 The function of a network layer, to route data through the network and set up
 a connection between two end points, is also needed in a LAN.  Basic LAN
 routing, error control, and flow control is defined as part of the LLC
 sublayer while the network layer may be a null layer.
 In summary, logical link control provides a consistent view of a LAN to the
 upper layers regardless of the media and protocols being used and may support
 all required end-to-end connectivity services.
 The interface to the upper layers is provided through LLC SERVICE ACCESS
 POINTS (LSAP), just as Service Access Points (SAPs) are the architected
 interfaces between any two adjacent layers in the OSI Reference Model
 Figure 33 under heading "3.1.2  OSI and SNA Models".  A station can have more
 than one SAP associated with it for a specific layer, just as a station may
 have more than one session active via one SAP. Any link level connection of
 one station to another is known as a LINK, while at each end of a link,
 associated control support is referred to as a LINK STATION.  In the remainder
 of this section, a LLC service access point will be referred to as a SAP.
 For example, a LAN station may have a 802.2 LLC level session through SAP
 X'04' with SAP X'08' in a token-ring attached 3174-01L, and concurrently be in
 session with a file server in another LAN station through SAP X'F0'.  Logical
 link control provides the capability to manage these independent sessions.
 +------------------------------------------------------------------------------
 ]
 ]              Station A           Station B              Station C
 ]                                   x    y
 ]                                   ]    ]
 ]                                   V    V
 ]            ]              ]    ]              ]       ]              ]
 ]            ]         (A1) ]    ](B1) (B2) (B3)]       ] (C1) (C2)    ]
 ]            ]---------(  )-]    ](  )-(  )-(  )]       ]-(  )-(  )----]
 ]            ] LLC       o  ]    ]  o    A      ]       ]  A      LLC  ]
 ]            ]-----------o--]    ]--o----+------]       ]--+-----------]
 ]            ] MAC       o  ]    ]  o    ]      ]       ]  ]      MAC  ]
 ]            ]-----------o--]    ]--o----+------]       ]--+-----------]
 ]         ===] Phys.     o  ]====]  o    ]      ]=======]  ]      Phys.]====
 ]            *-----------o--*    *--o----+------*       *--+-----------*
 ]                        oooooooooooo    *-----------------*
 ]          Medium
 ]         ==================================================================
 +------------------------------------------------------------------------------
 Figure 39. SAPs and LLC Connections
 In Figure 39 under heading "3.2.2  Logical Link Control Sublayer", application
 x is using SAP (B1) to communicate with a resource in station A. Assume that
 this resource is a printer.  A connection is set up between SAP (B1) and (A1).
 Once this connection is established, output can be sent to the printer.  At
 the same time, application y, using SAP (B2),  can have a connection with a
 resource in station C using SAP (C1).  The use of Service Access Points allows
 the applications and upper layer protocols to concurrently access the
 adapter(s) and media of the LAN.
 Another way to describe an LLC SAP is to define it as an architected code
 point between DLC and the upper layers identifying an application to the LLC
 sublayer.  The IEEE standard defines a number of SAP addresses, while the IBM
 Token-Ring Network Architecture uses a number of user-reserved SAP addresses
 to interface with IBM proprietary protocols. Before detailing the architected
 SAP values in use on IEEE LANs, it is necessary to describe bit ordering
 techniques. These have equal applicability to MAC addresses, in fact, one of
 the easiest places to see the various techniques is to trace TCP/IP Address
 Resolution protocols.

 3.2.2.1.1  Canonical Bit Ordering:  In the documentation produced by the
 standards bodies, a different method of bit ordering is used to that commonly
 accepted in the IBM world. The "standard" way of describing the order of bits
 in a byte is known as CANONICAL BIT ORDERING and is the reverse of the way IBM
 usually writes binary values. Depending on whose documentation is being
 studied, and when trying to relate the sets of documentation to each other,
 confusion may result. Also, when tracing a token-ring, a field containing a
 station address field may be present within the data. This field may be in
 canonical bit order, and has to be translated into the IBM order if sense is
 to be made of it.  Hence an explanation of this technique here.  For example:
 The decimal number 71 has a hexadecimal value of 47.  IBM would write this
 value, in binary, as
   0100 0111
 In canonical form, this same binary value would be read right to left, so as
 to look like:
   1110 0010
 If we take a much longer bit stream, such as a station MAC address, then:
     1    0    0    0    5    A    1    7    5    8    6    9

   0001 0000 0000 0000 0101 1010 0001 0111 0101 1000 0110 1001

   Canonically

   0000 1000 0000 0000 0101 1010 1110 1000 0001 1010 1001 0110

    0     8    0    0    5    A    E    8    1    A    9    6

 The order of the bytes remains the same, but each byte has its binary digits
 read from right to left when converting from the IBM form to the canonical
 form.
 Canonical bit ordering has particular relevance when looking at SAP values,
 and the reasons why SAP values are numbered in the way in which they are.

 3.2.2.1.2  SAP Values The structure of the format of the source SAP and
 destination SAP fields within the LLC Protocol Data Unit is shown in Figure 40
 under heading "3.2.2.1.2  SAP Values".
 -------------------------------------------------------------------------------

 IBM bit ordering

          *-----------------*
          ]D]D]D]D]D]D]U]I/G]  Destination SAP field (DSAP)
          *-----------------*

          *-----------------*
          ]S]S]S]S]S]S]U]C/R]  Source SAP field (SSAP)
          *-----------------*

 Canonical bit ordering

          *-----------------*
          ]I/G]U]D]D]D]D]D]D]  DSAP
          *-----------------*

          *-----------------*
          ]C/R]U]D]D]D]D]D]D]  SSAP
          *-----------------*

   C/R  Command/Response bit - 0=Command    1=Response
   U    User defined SAP     - 0=User       1=Standard
   I/G  Individual/Group SAP - 0=Individual 1=Group
 -------------------------------------------------------------------------------
 Figure 40. SAP Fields - Bit Ordering
 Since the C/R bit of the SSAP is not used as a bit within a SAP address, there
 are in fact only 128 possible SSAP values. A group SAP can only be used as a
 destination SAP, and is a special case of one of the 128 possible SAP values.
 These 128 SAPs are then divided into two groups, each with 64 values. If the
 bits of the SAP are shown in canonical order, binary values '100 0000' to '111
 1111' are reserved for IEEE use.  SAPs '000 0000' to '011 1111' are for users.
 The pattern of SAP values can now be more easily seen, than if they were
 represented in IBM bit order.  Whether the Group SAP bit is on or not, makes
 no difference to the allocation. A list of architected SAP addresses is
 provided in Figure 41 under heading "3.2.2.1.2  SAP Values" . This shows the
 SAP values in canonical form, together with their IBM hexadecimal
 representation.

   *---------------------------------------------------------------*
   ]I/G U         ]IBM HEX] Definition                             ]
   ]---------------------------------------------------------------]
   ]IEEE SAPs   U bit = 1                                          ]
   ]---------------------------------------------------------------]
   ] 0  0 00 0000 ] X'00' ] Null SAP                               ]
   ]              ]       ]                                        ]
   ] 0  1 00 0000 ] X'02' ] LLC Sublayer Management                ]
   ]              ]       ]                                        ]
   ] 0  1 00 bbbb ] X'x2' ] Network Mgt Function                   ]
   ]              ]       ]                                        ]
   ] 1  1 00 0000 ] X'03' ] Group LLC Sublayer management          ]
   ]              ]       ]                                        ]
   ] 0  1 10 0000 ] X'06' ] D.O.D. Internet                        ]
   ]              ]       ]                                        ]
   ] 0  1 10 bbbb ] X'x6' ] National Stds Bodies                   ]
   ]              ]       ]                                        ]
   ] 0  1 11 0000 ] X'0E' ] Proway network management - maintenance]
   ]              ]       ]   and initialization.                  ]
   ] 0  1 11 0010 ] X'4E' ] Manufacturing message service (MMS)    ]
   ]              ]       ]                                        ]
   ] 0  1 11 1110 ] X'7E' ] ISO 8208 (X.25 PLP)                    ]
   ]              ]       ]                                        ]
   ] 0  1 11 0001 ] X'8E' ] Proway active station list maintenance ]
   ]              ]       ]                                        ]
   ] 0  1 11 1111 ] X'FE' ] OSI Network Layer protocols            ]
   ]              ]       ]                                        ]
   ] 0  1 01 0101 ] X'AA' ] Subnetwork Access Protocol (SNAP)      ]
   ]              ]       ]                                        ]
   ] 0  1 00 0010 ] X'42' ] Bridge Spanning Tree protocol          ]
   ]              ]       ]                                        ]
   ] 1  1 11 1111 ] X'FF' ] Global SAP                             ]
   ]---------------------------------------------------------------]
   ]bbbb can be anything except B'0000'                            ]
   ]---------------------------------------------------------------]
   ]---------------------------------------------------------------]
   ]IBM defined SAP values U bit = 0                               ]
   ]---------------------------------------------------------------]
   ] 0 0 10 0000  ] X'04' ] SNA Path Control Individual            ]
   ]              ]       ]                                        ]
   ] 1 0 10 0000  ] X'05' ] SNA Path Control Group                 ]
   ]              ]       ]                                        ]
   ] 0 0 00 1111  ] X'F0' ] NETBIOS                                ]
   ]              ]       ]                                        ]
   ] 0 0 10 1111  ] X'F4' ] LAN Management Individual              ]
   ]              ]       ]                                        ]
   ] 1 0 10 1111  ] X'F5' ] LAN Management Group                   ]
   ]              ]       ]                                        ]
   ] 0 0 01 1111  ] X'F8' ] IMPL                                   ]
   ]              ]       ]                                        ]
   ] 0 0 11 1111  ] X'FC' ] Discovery                              ]
   ]              ]       ]                                        ]
   ] 0 0 11 1011  ] X'DC' ] Dynamic Address Resolution             ]
   ]              ]       ]      (Name Management)                 ]
   ] 0 0 10 1011  ] X'D4' ] Resource Management                    ]
   *---------------------------------------------------------------*
 Figure 41. Architected LLC Service Access Points
 Figure 42 under heading "3.2.2.1.2  SAP Values" illustrates how SAPs might be
 implemented in a station to provide logical interface points for different
 higher-layer protocols (including SNA path control), to acquire data link
 control services.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]               ]                  SNA System                   ]   OSI  ]
 ]               ]                                               ] System ]
 ]               ]- - - - - - - - *                              ]- - - - ]
 ]               ] SNA DLC Manager]                              ]        ]
 ]       LLC     ]                                               ]   ISO  ]
 ]       User    ] LLC Sub-layer  ]                              ] Network]
 ]               ] Management       (DLC Manager / Path Control) ]  Layer ]
 ]               ]                ]                              ]        ]
 ]       = = = = = = *--* = = = = = = =*--*= = =*--*= = =*--*= = = =*--*= =
 ]               ] ] ]02] ]       ]   ]]04]     ]08]     ]0C]]   ]  ]FE]  ]
 ]       LLC     ] ] *--* ]           ]*--*     *--*     *--*]   ]  *--*  ]
 ]       Sub-    ] *------*       ]   *----------------------*   ]        ]
 ]       layer   ]group SAP 03              group SAP 05         ]        ]
 ]               ]                ]                              ]        ]
 ]               *--------------------------------------------------------*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 42. LLC Service Access Points and SNA

 3.2.2.2  IEEE 802.2, ISO 8802-2
 To satisfy the broad range of potential applications, IEEE 802.2 logical link
 control defines different types of operation.  These types of operation, each
 representing a number of link-level services, are combined in several SERVICE
 CLASSES.
 o   TYPE 1,  CONNECTIONLESS OPERATION

     The Connectionless services are also referred to as USER DATAGRAM mode of
     operation.  In this mode, there is no data link connection establishment
     between the SAPs of the end stations before actual information frame
     transmission starts. At the LLC level there is no guaranteed delivery of
     frames to the destination station. There is no correlation between frames
     in a particular data transmission, and the sender does not expect an
     LLC-level acknowledgement.  In this mode of operation, higher layer
     services must provide recovery and frame sequencing.
 o   TYPE 2,  CONNECTION-ORIENTED OPERATION

     Prior to data exchange, a data link connection must be established, for
     which a LLC Type 2 control block has been defined.  These control blocks
     together with the associated delivery and error recovery services are
     called LINK STATIONS.

     The line protocol which is maintained on an established link between end
     stations is HDLC ASYNCHRONOUS BALANCED MODE EXTENDED.  In this way
     reliable end-to-end service for high traffic rates is provided.

     Essentially, the LLC Type 2 services may be summarized as:
     -   Sequence numbering of data frames at the data link layer.
     -   Error detection and basic recovery.
     -   Flow control.

     This also includes an LLC-level acknowledgement, for which a WINDOW SIZE
     of up to 127 outstanding frames may be sent before expecting
     acknowledgement from the destination station.
 o   TYPE 3,  ACKNOWLEDGED CONNECTIONLESS OPERATION

     This third mode of operation has been proposed as an enhancement to the
     international standard.

     In this mode, there is no connection establishment prior to data exchange,
     as in datagram operation. But link-level acknowledgement, consistent with
     the window size in use, is expected by the sending station.

     Type 3 operation seems particularly appropriate for LANs which experience
     traffic patterns with unpredictable bursts in message rates, such as a LAN
     with file servers or backbone traffic.
 Currently two classes of LLC operation are defined within the IEEE 802.2
 Standard based upon the above Type 1, Type 2, and Type 3 services:
 o   Class I - has Type 1 service only
 o   Class II - has Type 1 and Type 2 service.
 o   LLC Service
 However, as more types of LLC service are defined, there is a move to drop the
 concept of classes, due to the greater number of combinations of service, and
 hence classes, that would be created.

 3.2.2.3  LLC Protocol Data Unit
 Figure 43 under heading "3.2.2.3  LLC Protocol Data Unit" shows the format of
 a logical link control protocol data unit (LPDU) and the code bits for
 identifying each of the LLC services for both connectionless and
 connection-oriented modes of operation.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                       ]<---- LLC protocol data unit ---->]
 ]     *------------------------------------------------------------------*
 ]     ] MAC Header ] RI ]DSAP]SSAP] CF ] Information Field ] MAC Trailer ]
 ]     *------------------------------------------------------------------*
 ]                    ]    ]    ]    ]           ]
 ]          Routing --*    ]    ]    ]           *-- 0, 1, or more bytes
 ]          Information    ]    ]    *----- Control Field, 1 or 2 bytes
 ]          (optional)     ]    ]        bit 0             7 0              7
 ]                         ]    ]           *---------------------------------*
 ]     Destination SAP ----*    ]  I-Format ] ] ] N(S)] ] ]0] ] ] N(R)] ] ]P/F]
 ]     *-----------------*      ]           *---------------------------------*
 ]     ]D]D]D]D]D]D]U]I/G]      ]           *---------------------------------*
 ]     *-----------------*      ]  S-Format ]0]0]0]0]F]F]0]1] ] ] N(R)] ] ]P/F]
 ]      0 1 2 3 4 5 6  7        ]           *---------------------------------*
 ]     *-----------------*      ]           *-----------------*
 ]     ]S]S]S]S]S]S]U]C/R]      ]  U-Format ]M]M]M]P/F]M]M]1]1]
 ]     *-----------------*      ]           *-----------------*
 ]     Source SAP --------------*        bit 0               7
 ]
 ]
 ]      *--------------------------------------------------------------------*
 ]      ] Connection-Oriented Services                                       ]
 ]      ]--------------------------------------------------------------------]
 ]      ] Supervisory Function bits ]0 0]RR ]Receive Ready (cmd/resp)        ]
 ]      ] (S - Format)              ]0 1]RNR]Receive Not Ready (cmd/resp)    ]
 ]      ]                           ]1 0]REJ]Reject (cmd/resp)               ]
 ]      ]--------------------------------------------------------------------]
 ]      ] Modifier Function bits ]0 0 0   1 1]DM   ]Disconnect Mode resp     ]
 ]      ] (U - Format)           ]0 1 0   0 0]DISC ]DISConnect cmd           ]
 ]      ]                        ]0 1 1   0 0]UA   ]Unnumbered Ackn resp     ]
 ]      ]                        ]0 1 1   1 1]SABME]Set Asynch Balanced Mode ]
 ]      ]                        ]           ]     ]    Extended cmd         ]
 ]      ]                        ]1 0 0   0 1]FRMR ]FRaMe Reject resp        ]
 ]      ]                        ]           ]     ]    (5 byte I-field)     ]
 ]      ]                        ]1 0 1   1 1]XID  ]eXchange IDentification  ]
 ]      ]                        ]           ]     ]    cmd/resp (3 byte I-f)]
 ]      ]                        ]1 1 1   0 0]TEST ]TEST cmd/resp            ]
 ]      ]                        ]           ]     ]    (optional I-field)   ]
 ]      ]--------------------------------------------------------------------]
 ]      ] Connectionless Services                                            ]
 ]      ]--------------------------------------------------------------------]
 ]      ] Modifier Function bits ]0 0 0 0 0 0]UI   ]Unnumbered Inform. cmd   ]
 ]      ] (U - Format)           ]1 0 1   1 1]XID  ]eXchange IDentification  ]
 ]      ]                        ]           ]     ]    cmd/resp (3 byte I-f)]
 ]      ]                        ]1 1 1   0 0]TEST ]TEST cmd/resp            ]
 ]      ]                        ]           ]     ]    (optional I-field)   ]
 ]      *--------------------------------------------------------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 43. IEEE 802.2 LLC Protocol Data Unit Format
 Each LPDU consists of a destination and source SAP address field, a control
 field and an information field of zero or more bytes.  The following table
 lists the abbreviations used in this figure:
 o   D = Destination SAP bits.
 o   S = Source SAP bits.
 o   U = User-defined address bit (B'1' if IEEE defined).
 o   I/G = Individual (B'0') or group (B'1') SAP address.
 o   C/R = Command (B'0') or response (B'1') LPDU.
 o   N(S) = Transmitter send sequence number.
 o   N(R) = Transmitter receive sequence number.
 o   P/F = Poll/final bit.
 o   F = Supervisory function bit.
 o   M = Modifier function bit.

 3.2.2.3.1.1  DSAP Field:  The destination service access point (DSAP) address
 field identifies one or more service access points for which the information
 is intended.
 This eight-bit field contains one bit to identify whether the address is an
 individual or a group address, and seven address bits.  Two group addresses
 have specific IEEE standard definitions:

 o   Global address.

     If the DSAP field contains B'11111111', it is a global address (the frame
     is addressed to all SAPs).
 o   Null address.

     If the DSAP field contains B'00000000', it is a null SAP address,
     applicable only to connectionless operation.  It supports response to a
     TEST or XID command in those situations where no SAP has yet been
     activated in the remote node.

 3.2.2.3.1.2  SSAP Field:  The source service access point (SSAP) address field
 identifies the service access point which sent the frame.
 This eight-bit field contains a bit to identify whether the frame is a command
 or a response, and seven address bits.  The command/response bit is not
 considered as part of the source SAP address in a received frame.
 The low-order bit in the seven address bits of both DSAP and SSAP indicate an
 IEEE defined SAP address when set to B'1'.

 3.2.2.3.1.3  Control Field:  The control field is a one- or two-byte field
 used to designate command and response functions.  It contains sequence
 numbers when required.  The control field is very similar to the HDLC control
 field.  Its contents for different LLC services are outlined in Figure 43
 under heading "3.2.2.3  LLC Protocol Data Unit".

 3.2.2.3.1.4  Information Field:  The information field contains zero or more
 bytes of information, depending on the particular LLC service contained in the
 control field.
 A LLC PDU is invalid under the following conditions:
 o   It is identified by the physical layer or MAC sublayer as being invalid.
 o   The frame is not an integral number of bytes in length.
 o   It does not contain properly formatted address fields.
 o   The frame contains mandatory fields that are out of order.
 o   The frame length is less than three bytes for a one-byte control field, or
     less than four bytes for a two-byte control field.
 Invalid protocol data units are ignored.

 3.3  LAN Standards Summary
 IBM participates in most of the major LAN standards making organizations,
 including IEEE, ISO and ANSI, at international and local level.  IBM has
 provided many submissions in the area of LAN standardization, and has taken
 steps to ensure that IBM LAN products support or closely follow these
 standards.  IBMs active role in standards activity is particularly
 demonstrated by the SRT Bridge suggestions to IEEE 802.1D.
 IBM participates in the Manufacturing Automation Protocol (MAP) project, and
 has been active in the development of the FDDI standard, particularly within
 the area of the complex protocols of station management.
 Although the IBM PC Network adopts some of the concepts that are used by IEEE
 802.3, it cannot be considered a standard product, differing from IEEE 802.3
 in terms of the media and transmission speeds utilized. However, the IBM
 Token-Ring Network fully conforms to (and enhances) the IEEE 802.5 and 802.2
 standards.   IBM has participated in and supported the following enhancements
 to the IEEE 802.5 specifications:
 o   16 Mbps as a standardized transmission speed
 o   Early token release as an option
 o   Source routing bridge protocols.
 These proposals are in the process of being approved for inclusion in the
 international standard.
 IBM devices attach to IEEE 802.3, IEEE 802.4 and IEEE 802.5 networks, and
 implement IEEE 802.2 protocols. IBM has said that it will, in time, support
 ISO 9314 FDDI networks.
 IBM is supporting ISO management on its LANs, with the IBM LAN Station Manager
 product, and using the OSI CMIP protocol to convey management information. IBM
 is supporting international standards, and the advent of the concept of
 HETEROGENEOUS LAN MANAGEMENT, a joint project between IBM and 3Com, means that
 a managed LAN environment, no matter on what topology or technology it is
 based, could become a practical possibility.

 4.0 Structured Wiring
 Standard wiring between telephone plugs in an office area and (automated)
 patch panels has been a common practice for some time.  This has not generally
 been true for data communications where workstations have been connected from
 their particular locations to control units in other locations by pulling
 dedicated coaxial or twinaxial cables.  The choice of cable type for data
 communications has also been rather restrictive with respect to the variety of
 devices that may be attached to a particular type of cable.  In an
 unstructured wiring environment, every relocation or change in type of a
 device may require considerable planning and installation effort due to these
 factors.
 The emergence of intelligent workstations has led to significant changes in
 application connectivity: from the traditional hierarchical host-workstation
 connectivity to a mixture of hierarchical and peer-to-peer connectivity  such
 as that between intelligent workstations used as LAN requesters and servers.
 For these reasons, a structured and consistent wiring approach to address the
 cabling requirements for a large number of different devices and their
 attachments has become important to many organizations.

 4.1.1  Star-Wired Environments
 The basic idea of structured wiring is to pre-wire work areas with
 high-quality cables running to central locations, called WIRING CLOSETS where
 every permanent wire ends at a DISTRIBUTION PANEL.  The overall purpose is to
 simplify moves, changes and reconfigurations.
 Any change in the location or characteristic of a workstation would usually
 require only a different connection via jumpers at the distribution panel.
 More substantial changes in the topology of the attachments would usually be
 accomplished by adding components in the wiring closet to support the new
 wiring or attachment requirements, or by pulling additional wire (such as
 fiber cable) through the shorter and more accessible runs between the wiring
 closets.  Thus the use of a star-wired approach minimizes the costs of
 maintenance by ensuring that the areas subject to the greatest change are the
 areas that are the most accessible and least expensive to change from an
 equipment and labor standpoint.  The same structuring also provides simpler
 problem determination and recovery procedures, since the connection points are
 clustered in the wiring closets where they are more readily identified and
 where backup ports can be accessed.

 4.1.2  Other Wiring Environments
 Other requirements, such as very small networks or the need for broadband
 transmission (to support both CATV and data transmission) may lead to
 different wiring approaches from the star-wired approach identified above.
 IBM PC Network implementations provide cabling kits or accessories to address
 either of these requirements.
 The IBM PC Network (Broadband) LAN is a 2 Mbps CSMA/CD driven local area
 network, offered with IBM-supplied cabling kits, referred to as SHORT, MEDIUM
 AND LONG DISTANCE KITS.  The cable type used is CATV cable. The wiring is
 dedicated for use in the PC Network (Broadband) and is not used for other
 devices or transmission.  With custom wiring using more sophisticated
 transmitters, the other CATV cable channels may be used for other purposes
 such as closed-circuit TV.  For more details, see "5.1.3 IBM PC Network
 (Broadband) Components."
 IBM PC Network Baseband is a low-cost 2 Mbps CSMA/CD driven local area
 network, using twisted pair wire to connect its LAN stations into one or more
 daisy-chains. A PC Network Baseband adapter cable may be obtained to take
 advantage of the IBM Cabling System in wiring this LAN. "5.2 IBM PC Network
 Baseband" provides more details on this LAN offering.

 4.2  IBM Cabling System
 The IBM Cabling System provides specifications for components and their use in
 structured pre-wiring of buildings.  The components include cables,
 connectors, wall faceplates, and wiring closet distribution  panels.
 While IBM helped design specifications for the cabling system, manufacturing,
 distribution, installation, and maintenance is done by third parties.
 The IBM Cabling System provides the elements of a common wiring system capable
 of supporting most existing and future IBM workstation equipment, in addition
 to several host processors.  Today, the IBM Cabling System consolidates coax,
 twinax and telephone twisted pair wire transmission support into a
 multi-purpose quality twisted pair wire (data grade shielded twisted pair).
 The wiring specifications also permit cost-effective use of fiber cables for
 backbone wiring.  In addition to providing bandwidth for future traffic
 requirements, the use of fiber backbone cables enables an establishment to
 install wiring with the potential to support possible FDDI LAN requirements.
 The IBM Cabling System components are designed to support a concept of
 structured wiring minimizing the impact of replacement or relocation of
 equipment. It may be used to pre-wire buildings for all equipment, or to
 provide additional cable runs for new equipment in existing buildings.  While
 the IBM Cabling System provides specifications for several different types of
 cable (some of which also support voice transmission), other types may also be
 supported by the cabling system components subject to attenuation and
 signalling characteristics.  Figure 44 under heading "4.2  IBM Cabling System"
 illustrates the eight cable types defined within the IBM Cabling System and
 described in IBM cable planning reference manuals.(10 under heading "4.2  IBM
 Cabling System")

 ---Footnote---
 (10)

 USING THE IBM CABLING SYSTEM WITH COMMUNICATION PRODUCTS (GA27-3620).
 IBM CABLING SYSTEM PLANNING AND INSTALLATION GUIDE (GA27-3361).

 --------------

 +------------------------------------------------------------------------------
 ]
 ]   *---------------------------------------------------------------*
 ]   ]       ]         ]          ]           ]        ]             ]
 ]   ] Cable ]Conductor] Pairs    ] Shielding ]Outdoor ] Use         ]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 1 ]Solid    ]Two AWG 22] Braided or]  Yes   ] Main Paths  ]
 ]   ]       ]Copper   ]Twisted   ] Corrugated]  (1)   ]Work Area to ]
 ]   ]       ]         ]          ]           ]        ]Wiring Closet]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 2 ]Solid    ]Two AWG 22] Braided   ]   No   ]Work Area to ]
 ]   ]       ]Copper   ]Twisted  +]           ]        ]Wiring Closet]
 ]   ]       ]         ]Four TTP  ]   No      ]        ]             ]
 ]   ]       ]         ] (AWG 22) ]           ]        ]             ]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 3 ]Solid    ]Four TTP  ]   No      ]   No   ]Work Area to ]
 ]   ]Specs  ]Copper   ] (AWG 26) ]           ]        ]Wiring Closet]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 5 ]Fiber    ]Two Fiber ]   No      ]  Yes   ] Main Paths  ]
 ]   ]       ]Optics   ] 100/140  ]           ]        ](inter Bldg) ]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 5J]Fiber    ]Two Fiber ]   No      ]  Yes   ] Main Paths  ]
 ]   ]       ]Optics   ]  50/125  ]           ]        ](up to 500m) ]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 6 ]Stranded ]Two AWG 26] Braided   ]   No   ]Work Area and]
 ]   ]       ]Copper   ]Twisted   ]           ]        ]Wiring Closet]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 8 ]Solid    ]Two AWG 26] Braided   ]   No   ]Work Area    ]
 ]   ]       ]Copper   ]Parallel  ](each pair)]   No   ]Under carpet ]
 ]   ]-------+---------+----------+-----------+--------+-------------]
 ]   ]Type 9 ]Solid    ]Two AWG 26] Braided   ]   No   ] Main Paths  ]
 ]   ]       ]Copper   ]          ]           ]        ] (plenum)    ]
 ]   *---------------------------------------------------------------*
 ]
 ]            Note 1. Plain, Plenum and Outdoor versions
 ]            TTP = Telephone Twisted Pair
 ]            AWG = American Wire Gauge
 ]
 ]o   Type 1 - Shield around two twisted pair of No. 22 AWG solid copper
 ]    wire.
 ]o   Type 2 - Same as the Type 1 cable with the addition of four twisted
 ]    pair No. 22 AWG telephone conductors.
 ]o   Type 3 - telephone twisted pair specification, No. 22 or No. 24 AWG
 ]    solid copper wire.
 ]o   Type 5/5J - Two optical fiber conductors, 100/140 and 50/125 (fiber
 ]    core/cladding size in microns), other sizes may also be used (for
 ]    example, 62.5/125 micron).
 ]o   Type 6 - Shield around two twisted pair of No. 26 AWG solid copper
 ]    wire used for patch cables.
 ]o   Type 8 - Undercarpet cable, two pair No. 26 AWG solid copper wire,
 ]    with shielding.
 ]o   Type 9 - Two No. 26 AWG solid copper wire, offered as a lower cost
 ]    alternative to type 1 plenum (11 under heading "4.2  IBM Cabling System")
 +------------------------------------------------------------------------------
 Figure 44. Cable Types

 ---Footnote---
 (11) Plenum refers to space in the ceiling of a building floor frequently used
 to run cable ducts.  In such cases, local regulations may require the
 installation of plenum cable that has a teflon coating instead of regular PVC.
 --------------

 There are many advantages to structured wiring systems incorporating
 general-purpose cable and components:
 o   Minimal additional cost of adding a new terminal. The provision of cable
     and wall outlets at each workplace makes it possible to "plug in" the new
     equipment.
 o   Easier and less disruptive movement of equipment.  With a wiring closet
     structure, most changes are made in the wiring closet, minimizing the need
     to pull or relay new cable.  Where changes are required, they can usually
     be confined to the more accessible wiring closets and shorter cable runs
     between the wiring closets.
 o   Simpler problem determination and maintenance. The knowledge of which
     cable is installed and where helps to minimize cost and time spent
     associated with maintenance or problem determination.
 A key element in problem determination at this level is proper documentation
 of the cabling system installation, see USING THE IBM CABLING SYSTEM WITH
 COMMUNICATION PRODUCTS.  Also refer to recommendations for labelling schemes,
 worksheets and charts to document the installation in the IBM CABLING SYSTEM
 PLANNING AND INSTALLATION GUIDE.
 The fiber cabling accessories, attachments, and planning guidelines supplied
 by IBM support the most popular multimode optical fiber specifications,
 including 50/125 micron, 62.5/125 micron, 85/125 micron, and 100/140 micron
 cables.  Because the FDDI LAN specifies 62.5/125 micron optical fiber, many
 customers may wish to use 62.5/125 micron multimode optical fiber cable in
 their token-ring network installations.  Alternatively, they could use the
 50/125 micron specification for those countries where 62.5/125 micron is not
 commonly used or available.  85/125 or 100/140 micron optical fiber cable are
 supported, but are not recommended for new installations by customers
 considering use of FDDI for future applications.
 For IBM recommendations on fiber optic cabling, please refer to "2.1.1.2 Fiber
 Optic Cable."

 5.0 IBM Local Area Network Solutions
 IBM provides three local area network implementations:

 o   IBM Token-Ring Network
 o   IBM PC Network (Broadband)
 o   IBM PC Network Baseband.
 IBM has also announced products that implement station attachment to LANs
 based upon the Manufacturing Automation Protocols (MAP) 3.0 specification,
 including IEEE 802.4 networks.
 IBM also provides attachment of some of its products to Ethernet Version 2 and
 IEEE 802.3 networks. Products that may attach include PC and PS/2 workstations
 running DOS or OS/2 operating software, PC RTs and RS/6000 processors, and the
 IBM 8209 LAN bridge that may be used to link Ethernet/IEEE 802.3 LAN segments
 to token-rings. Gateway support to IBM hosts is provided by both the IBM 8232
 and IBM 3172 Interconnect Controllers.

 5.1  IBM Token-Ring Network
 The IBM Token-Ring Network uses baseband transmission at either 4 Mbps or 16
 Mbps implementing the IEEE 802.5 standard MAC protocols and the IEEE 802.2
 Class II standard LLC protocols.  At 16 Mbps, the IBM Token-Ring Network
 implements the early token release option.
 Devices operating at 4 Mbps and others operating at 16 Mbps cannot be
 intermixed on the same LAN segment.  Any attempt to insert a device into the
 ring at the wrong data rate will cause the ring to fail for several seconds
 due to the recovery process.
 The IBM Token-Ring Network uses a star-wired logical ring topology.  Devices
 on the network are physically attached to wiring concentrators.  The wiring
 concentrator or access unit may be passive, such as the IBM 8228, known as a
 MULTISTATION ACCESS UNIT (MSAU).  or active devices such as the IBM 8230
 Controlled Access Unit (CAU).  The access unit is used as a point to control
 physical access to the ring, and to provide a method to bypass faulty or
 inactive devices.  Use of an access unit avoids the following problems
 inherent in a physical ring topology:
 o   RELIABILITY

     Failure of a ring station may disrupt the ring due to the loss of signal
     regeneration.  Without a station bypass mechanism, the failure of a single
     station could stop all ring traffic, affecting all other ring devices. A
     cable fault between adjacent LAN stations in a physical ring topology can
     also stop normal operation of the LAN.
 o   SERVICEABILITY

     Changing the configuration of the network (or even adding a new LAN
     station) could be disruptive if a controlled insertion process is not
     implemented.
 Using a wiring concentrator can alleviate or remove these problems.  For
 example, having a wiring concentrator that bypasses any inactive station means
 that when a station fails or a cabling fault occurs in an attaching cable, the
 ring is not disrupted.  Stations can be added or removed from the ring while
 it is running without affecting other users in the network.

 5.1.1  IBM Token-Ring Network Components

 5.1.1.1  Cabling Components
 The IBM Token-Ring Network is designed to make use of a structured wiring
 system, like the IBM Cabling System mainly because of its star-wired ring
 topology.  Maximum flexibility may be obtained when a building is wired with
 conveniently located wiring closets containing wiring patch panels and
 token-ring access units.
 The IBM Token-Ring Local Area Network can be used with all the cable types
 referred to in Figure 44 under heading "4.2  IBM Cabling System" when
 installed in conformance with the planning and installation specifications of
 the IBM Cabling System as described in the IBM TOKEN-RING NETWORK INTRODUCTION
 AND PLANNING GUIDE.  Type 1 or 2 cables should be used for lobes (the
 connection from the wall outlet to the workstation).  Cable Types 1, 2 and 5
 can be used for the links between the access units.
 In an IBM Token-Ring Network operating at 4 Mbps, Type 3 Telephone Twisted
 Pair (TTP) cable can be used to connect device attachment locations to access
 units in a wiring closet provided the Type 3 Cable Specifications for distance
 and number of station attachments are met, and the cable is not subject to
 electrical noise.  Type 3 TTP wire can be mixed with data grade media twisted
 pair wire within a single physical ring but cannot be used to wire a 16 Mbps
 token-ring LAN segment.
 Figure 45 under heading "5.1.1.1  Cabling Components" provides a schematic
 diagram of IBM Token-Ring Network stations connected via IBM Cabling System
 wiring and attachments.  The first part shows the use of data grade media
 twisted pair; the second illustrates installation requirements when using
 voice grade (telephone) twisted pair wire.
 +------------------------------------------------------------------------------
 ]
 ]                              **   Lobe :
 ]                              ]]   Type 1/2/9       inter-Wiring
 ]                              ]]   *-----------*    Closet : Type 1/9/5
 ]                              ]]   ]       *---]----------------<-------
 ]                              ]]   ]       ]   ]           from Previous
 ]                              ]]   ]       ]   ]         *------>-------
 ]                              ]]   ]      *]---]---------]*  to Next
 ]         *----*               ]]   ]     *-. .*. . . . . .-<-*
 ]         ]    ]               ]]   ]     ]]. .]. . . . . .]  ]
 ]         ]    ]               ]]   ]     ]]. .]. . . . . .]  ]
 ]        *------*              ]]   ]     V]. .]. . . . . .]  ]
 ]        ]      ]-----* Device ]]   ]     ]]. .]. . . . . .]  ]
 ]        *------*     ] Adapter]]   ]     ]]---]-----------]  ] Type 6
 ]                     ] Cable  ]]   ]     ]]---]-----------]  ] (patch
 ]                     *--------]]---*  AU *+. .*. . . . . .+* ] cable)
 ]                              ]]          ]---------------]] ]
 ]                              ]]          ]---------------]] ]
 ]                              ]]      AU *+. . . . . . . .+]-*
 ]                              ]]         ]]---------------]]
 ]                              ]]         *--------<--------*
 ]                              ]]          ]               ]
 ]                              ]]          ]               ]
 ]                           --------       -               -
 ]
 ]          DATA GRADE MEDIA TWISTED PAIR, 4 MBPS OR 16 MBPS
 ] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 ]
 ]
 ]                Type 3                    Voice  **
 ]                Jumper Cables             Pairs  ]]
 ]                      ]          Telephone  ]    ]]    Type 3 specs TTP
 ]         *-----------------*     Jumper     ]    ]]    ]
 ]         ]       *------*  ]     Wire-*     ]    ]]    ]      30 Mhz
 ]    *----]-------]--*   ]  ]    *--*  ]   *--*   ]]    ]      Media
 ]    ]. . .*. . . ] .]   ]  *----]  ]------]  ]---]]--------*  Filter
 ]    ]. . .]. . . .*.]   ]       ]  ]------]  ]   ]]        ] /
 ]    ]. . .]. . . .].]   ]       ]  ]------]  ]   ]]       *-*  *----*
 ]    ]. . .]. . . .].]   *-------]  ]------]  ]---]]---*   *-*  ]    ]
 ]    ]. . .]. . . .].]           *--*      *--*   ]]   ]    ]   ]    ]
 ]    ]-----]-------]-]               Type 66      ]]   ]    *---------*
 ]    ]-----]-------]-]               Termination  ]]   ]       ]      ]
 ]    ]. . .*. . . .*.] AU            Blocks       ]]  *-*      *------*
 ]    ]---------------]                            ]]  *-*
 ]    ]---------------]                            ]]   ]      *----*
 ]    ]o o o o o o o o]                            ]]   ]      ]    ]
 ]    ]---------------]                            ]]   ]      ]    ]
 ]    ]               ]                            ]]   *------------*
 ]    ]               ]                            ]]         ]      ]
 ]    -               -                         --------      *------*
 ]
 ]          VOICE GRADE TELEPHONE TWISTED PAIR, 4 MBPS ONLY
 ]
 +------------------------------------------------------------------------------
 Figure 45. IBM Cabling System in the IBM Token-Ring Network
 o   A maximum of 33 IBM 8228 Multistation Access Units is supported on a
     single ring running at 4 Mbps or 16 Mbps.  The maximum number of
     concurrently active devices on a 4 or 16 Mbps Token-Ring Network is 260.
 o   When Telephone Twisted Pair wire is being used a media filter must be
     installed between the station adapter card and the telephone jack in the
     wall.  Also the maximum number of concurrently active devices is 72 (TTP
     is supported by IBM running at 4 Mbps only).

     Two type 66 termination blocks are recommended to provide isolation
     between the data and voice pairs of the telephone wire.  Between a data
     termination block and the distribution panel a Type 3 jumper cable is
     used.

     The Telephone Twisted Pair wiring option may not be available in all
     countries due to PTT restrictions.
 o   For further information, refer to the following documentation:
     -   IBM CABLING SYSTEM PLANNING AND INSTALLATION GUIDE
     -   IBM TOKEN-RING NETWORK INSTALLATION GUIDE
     -   IBM TOKEN-RING NETWORK INTRODUCTION AND PLANNING GUIDE
     -   IBM TOKEN-RING NETWORK TELEPHONE TWISTED-PAIR MEDIA GUIDE
     -   IBM TOKEN-RING NETWORK TELEPHONE TWISTED-PAIR MEDIA GUIDE, European
         version.
 In addition to the specifications for numbers of attachments identified above,
 rules are also provided for maximum distances between stations which drive
 signals, and wiring closets (that is, maximum lobe distances) and between
 wiring closets.
 The number of stations attached to a token-ring LAN may be increased
 indefinitely by using token-ring bridges. For instance 4 Mbps ring segments
 may be interconnected with 16 Mbps segments via token-ring bridges; or voice
 grade (telephone) twisted pair wired ring segments may be interconnected with
 ring segments for which data grade media twisted pair wire has been used.
 IBM Token-Ring Network bridges are discussed in "6.0 LAN Segments
 Interconnection."

 5.1.1.1.1  IBM 8228 Multistation Access Unit The IBM 8228 Multistation Access
 Unit supports up to eight LAN stations via device attachment ports and the
 interconnection of multiple 8228 access units via ring-in, ring-out ports.
 The 8228 is a passive wiring concentrator that can bypass attached devices by
 reacting to the presence (or absence) of a signal from the device attachments.
 Each of the eight device attachment ports includes relay mechanism which is
 powered by a phantom current (12 under heading "5.1.1.1.1  IBM 8228
 Multistation Access Unit") from the attaching adapter.

 ---Footnote---
 (12) A 5 Volts DC voltage is sent by the attaching adapter over the lobe wire t
 power the relay. It is called a phantom current because it is transparent to th
 actual AC data signal.
 --------------

 In "2.2.2 Basic Token-Passing Ring Concepts," a sample wiring scheme involving
 four multistation access units (referred to as passive wiring concentrators)
 was described together with an illustration, in Figure 10 under heading "2.2.2
 Basic Token-Passing Ring Concepts", of a few active or inserted devices as
 well as several bypassed lobes.
 The backup scenario shows how the backup path is used to recover the ring
 traffic following a cable break between the ring-out position of one
 multistation access unit and the ring-in position of the subsequent
 multistation access unit. This recovery requires manual intervention to remove
 each end of the cable segment from the ring-in or ring-out ports, unless a
 pair of 8220 Optical Fiber Converters has been installed with the capability
 to isolate the broken segment (see "5.1.1.1 Cabling Components").

 5.1.1.2  IBM 8230 Controlled Access Unit
 The IBM 8230 is an intelligent token-ring network wiring concentrator,
 providing enhanced levels of control and reliability over passive token-ring
 network wiring concentrators, such as the IBM 8228.  It is designed to:
 o   Improve token-ring availability
 o   Support the IBM LAN Network Manager, see "9.3.5 IBM LAN Network Manager
     V1" by:
     -   Supporting IBM LAN Network Manager's configuration table
     -   Supporting access control by reporting station insertions
     -   Supporting asset control in conjunction with IBM LAN Network Manager.
 It is a customer set up, rack-mountable device that:
 o   Supports ring operation at 4 and 16Mbps
 o   Is able to function as a repeater in both ring directions
 o   Has pluggable ring-in and ring-out modules to support copper and fiber
     cable
 o   Has token-ring MAC appearances on both the main and backup ring path
 o   May have its microcode loaded from the IBM LAN Network Manager, or a
     diagnostic utility provided.
 One IBM 8230 attaches up to 80 workstations to the token-ring local area
 network (IEEE 802.5).
 Each IBM 8230 consists of two types of unit:
 o   A Controlled Access Unit Base (Base Unit).
 o   And up to four Lobe Attachment Modules (LAM).  Each LAM can attach 20
     devices to the ring.
 Although the 8230 operates at either 4 Mbps or 16 Mbps, unshielded twisted
 pair wiring on the lobes is only supported at 4 Mbps. In this case, a special
 media filter is required to be plugged into the control unit.
 The IBM 8230 works with both the copper and optical fiber cables of the IBM
 Cabling System. The ring-in and the ring-out connections are provided by two
 types of pluggable module, one suitable for copper, the other for fiber
 connections.  Thus the ring-in (RI) and ring-out (RO) connections to an 8230
 may be both copper, both optical fiber or one of each, depending on the RI and
 RO options installed in the control unit.
 The fiber RI and RO modules accept 50/125, 62.5/125, 85/125 and 100/140
 multi-mode optical fiber cables.  The optical fiber cable connections are via
 standard "Mini-BNC" optical fiber connectors.
 NOTE:  The 8230 is shipped with two copper RI/RO modules installed as standard
 equipment.  The optical fiber modules must be ordered as an optional feature.
 The 8230 can co-exist with the following products when installed in the same
 token-ring LAN: IBM 8218, 8219, 8220, 8228.
 o   The 8228 may be located between 8230 units but may not be connected
     directly to the 8230 lobes.
 o   The 8218s, 8219s, and 8220s may be used in pairs in the same ring.  The
     8230 CANNOT serve as one half of a repeater pair for any of these devices.
 When used without associated Lobe Attachment Modules (LAM), it can operate as
 a repeater, at either 4 Mbps or 16 Mbps, using optical fiber or copper media.
 A remote diagnostic tool will be shipped with the 8230. It comes on a DOS
 bootable diskette with each 8230. This tool is for use prior to the
 availability of IBM LAN Network Manager and generally for those customers who
 do not have IBM LAN Network Manager installed. The RDT will support up to 16
 8230's on a local segment. It can be used for diagnostics and problem
 determination purposes, and for remote program update.  The top level 8230
 microcode is updatable using the remote diagnostic tool or the Remote Program
 Update (RPU) enable facility of IBM LAN Network Manager in combination with a
 program update utility.
 Figure 46 under heading "5.1.1.2  IBM 8230 Controlled Access Unit" shows the
 IBM 8230 on an IBM Token-Ring Network.
 -------------------------------------------------------------------------------

                           *------------*
                           ]  IBM 8230  ]
                           ]            ]
      *--------------------] RO      RI ]---------------------------*
      ]                    ]            ]                           ]
      ]                    ]            ]                           ]
      ]                    *------------*                           ]
      ]<----- Main Ring Path (fiber or copper)            copper -->]
      ]                                                             ]
      ]                             *-------------------------------+--*
      ]                             ]                               ]  ]
      ]                             ] RI       IBM 8228             ]RO]
      ]                             ]                               ]  ]
      ]                             ] *-* *-**-**-**-**-**-**-**-* *-* ]
      ]                             ] *-* *-**-**-**-**-**-**-**-* *-* ]
      ]                             *--+------------------------+------*
      ]       Standard Patch Cable --->]                        ]
      ]                                *------------*           ]
      ]                                             ]           ]
      ]                                             ]           ]
      ]  *---------------------------------------*  ]           ]
      ]  ]   RI                            RO    ]  ]           ]
      ]  ]  *---*                         *---*  ]  ]           ]
      *--+--]   ]                         ]   ]--+--*           ]
         ]  *---*                         *---*  ]          *-------*
         ]             Control Unit              ]          ]       ]
         ]                                       ]          ] Node  ]
         ]                                       ]          ]       ]
         ]------------- IBM 8230  ---------------]          *-------*
         ]                                       ]
         ]    Lobe Attachment Module  LAM        ]
         ]*-* *-* *-* *-* *-* *-* *-* *-* *-* *-*]
         ]*-* *-* *-* *-* *-* *-* *-* *-* *-* *-*]
         ]                                       ]
         ]*-* *-* *-* *-* *-* *-* *-* *-* *-* *-*]
         ]*-* *-* *-* *-* *-* *-* *-* *-* *-* *-*]
         *-------------+-------------------------*
                       ]<------- Lobe
                   *-------*
                   ]       ]
                   ] Node  ]
                   ]       ]
                   *-------*

 NOTE:  Standard IBM Cabling System patch cables are used to connect the
 control unit and the LAMs (ICS version) to distribution panels.
 -------------------------------------------------------------------------------
 Figure 46. IBM 8230 on IBM Token-Ring Network

 5.1.1.2.1  Hardware Description:  The main parts of the control unit are power
 supply and logic unit.  The logic unit contains microprocessors and their
 associated microcode to direct the operation of the LAMs and to interact with
 the token-ring network for data transfer and communication.  The power supply
 provides DC power for the control unit and the associated LAMs.
 The LAM provides the interface to the lobe wiring connecting the workstations
 to the token-ring network.  It is available in two versions. One has IBM
 Cabling System (IEEE 802.5) connectors, the other RJ45 connectors.  It is
 possible to mix the LAM types within a single 8230.
 Each outlet of the LAM has a LED for status indication:
 o   Off      = Lobe enabled but not inserted.
 o   On solid = Lobe enabled and inserted.
 o   Blinking = Lobe disabled by 8230 or IBM LAN Network Manager.
 NOTE:  An ENABLED  lobe is one on which a station could insert.  A station
 attempting to insert on a DISABLED LOBE will not get onto the ring. Lobes are
 disabled and enabled by command from the IBM LAN Network Manager, or the CAU
 upon discovering a fault in this area.
 Attaching LAMs are "hot-pluggable", that is, they may be connected or
 disconnected from the control unit while power is applied.
 The 8230 uses three individual MAC addresses. Therefore it takes up three of
 the total number of adapters allowed on a single ring ( = 260 for ring cabled
 with Type 1 cable).
 Figure 47 under heading "5.1.1.2.1  Hardware Description" shows a functional
 diagram of the IBM 8230.  Reference to it should be made while reading the
 following text.
 The primary-in (PI) adapter is the first MAC entity on the main ring.  All
 token-ring data comes through PI just after entering the ring-in connector
 when the ring is operating normally.  PI reclocks and retransmits data as any
 typical station on the token-ring network.  The primary-out (PO) adapter is
 the second MAC entity on the main ring.  All token-ring data passes through PO
 just before exiting the ring-out port when the ring is operating normally.  PO
 reclocks and retransmits data as any typical station on the token-ring
 network.  The secondary (S) adapter is the MAC entity that resides on the
 backup path.  During normal ring operation, all data on the backup path passes
 through S.  S reclocks and retransmits data as any typical station on the
 token-ring network.
 -------------------------------------------------------------------------------

 *---------------------------------------------------------------*
 ] *------------*                               *------------*   ]
 ] ]            ]        *---------*            ]            ]   ]
 ] ]Power Supply]        ]S-Adapter]            ] Controller ]   ]
 ] ]            ]        *---------*            ]            ]   ]
 ] *------------*            ]]                 *------------*   ]
 ]                          *--*                                 ]
 ]                        *-]  ]---------*                       ]
 ]Ring-in      Wrap       ] *--*         ]   Wrap      Ring Out  ]
 ]Module       Relays     ]              ]   Relay       Module  ]
 ] *-*         *-* *-*    ]              ]   *-*             *-* ]
 ] ] ]         ]X] ]Y]    ]              ]   ]Z]             ] ] ]
 ]-] ]---------]X]-]Y]----*              *---]Z]-------------] ]-]
 ] ] ]         ]X] ]Y*-----------------------]Z]-----------* ] ] ]
 ] ] ]         ]X] ]YYYYYYYYYYYYYYYYYYYYYYYYY]Z]YYYYYYYYYYY] ] ] ]
 ] ] ]         ]X] *-------------------------]Z]---------*Y] ] ] ]
 ] ] ]  *--*   ]X]  *-*                      ]Z]   *--*  ]Y] ] ] ]
 ]-] ]--]  ]---]X]--] ]-*                 *--]Z]---]  ]--]Y]-] ]-]
 ] ] ]  ]  ]   ]X]  ] ] ]                 ]  ]Z]   ]  ]  *-* ] ] ]
 ] *-*  *--*   *-*  *-* ]                 ]  *-*   *--*      *-* ]
 ]       ]]       Filter]                 ]         ]]           ]
 ]  *----------*        ] *-* *-* *-* *-* ]    *----------*      ]
 ]  ]PI-Adapter]        *-] ]-] ]-] ]-] ]-*    ]PO-Adapter]      ]
 ]  *----------*          *-* *-* *-* *-*      *----------*      ]
 ]                         ]   ]   ]   ]                         ]
 ]                         ]   ]   ]   ]                         ]
 *---------------------------------------------------------------*
                          Lobe attachment
                         Module Connectors
 -------------------------------------------------------------------------------
 Figure 47. IBM 8230 Functional Diagram
 The function of these adapters and the wrap relays is to enable and control
 automatic ring re-configuration in the event of "hard" errors on the ring
 paths. How the IBM 8230 is able to react to these errors and reconfigure the
 ring will be shown later in "5.1.1.2.4 Reconfiguration."
 The diagram also shows the pluggable filter, required when the lobes use
 unshielded cabling. The purpose of the filter is to filter the signal being
 put on the first active lobe by the PI adapter.

 5.1.1.2.2  Management Support:  Under the control of IBM LAN Network Manager,
 the 8230 provides an optional means for controlling workstation access to the
 token-ring network and also for collecting realtime ring configuration or
 topology data.  A subset of LAN Station Manager V1 is implemented in the 8230
 in order to support communication with the IBM LAN Network Manager.  The
 following portions of the LAN Station Manager are supported:
 o   Name Management.  A Find/Found process will be executed to locate IBM LAN
     Network Manager for the registration process.  See "2.4.1.2 Registration."
 o   Resource Management.  This means, for example, to get the operation status
     of the 8230.
 The 8230 supports the IBM LAN Network Manager in the areas of access and asset
 control.  If no LAN Station Monitor exists in the workstation, then the 8230
 gives the following information directly to the IBM LAN Network Manager:
 o   Adapter address
 o   8230 number (last 4 digits of PO MAC address)
 o   Lobe Attachment Module number
 o   Lobe number.
 If there is a LAN Station Manager present in the workstation, the same
 information will flow via that Station Manager to the IBM LAN Network Manager.
 The 8230 transmits and receives frames from its designated MAC address which
 defaults to the MAC PO address.  The IBM LAN Network Manager communicates with
 the 8230 using this address.  In the event the IBM LAN Network Manager losing
 contact, it may send frames to the RING WIRING CONCENTRATOR FUNCTIONAL ADDRESS
 (X'C000 0000 1000').

 5.1.1.2.3  Cabling:  The 8230 supports the cable configurations in Figure 48
 under heading "5.1.1.2.3  Cabling" and Figure 49 under heading "5.1.1.2.3
 Cabling", provided that the cable plan meets all other requirements listed in
 IBM TOKEN-RING NETWORK INTRODUCTION AND PLANNING GUIDE and IBM TOKEN-RING
 NETWORK TELEPHONE TWISTED-PAIR MEDIA GUIDE.
 Although a mixture of IBM Cabling System Type 1 and Type 3 lobe wiring is
 supported on the same IBM 8230 Controlled Access Unit, it is recommended that
 only cabling type 3 (unshielded twisted pair) be used when the LAM is fitted
 with RJ45 connectors.  This is due to the physical constraints of attaching
 the small plugs to the thick cable.  For LAMs that have the IBM data
 connectors, a mixture of cabling can be used, but if there are any Type 3
 lobes attached to an IBM 8230 Controlled Access Unit and its associated LAMs,
 all lobes, whatever their cable type, must be fitted with the appropriate Type
 3 media filter, as well as a filter installed within the 8230 Control Unit.

 +----------------------------------------------------------------------------+
 ] Figure 48. Lobe Length                                                     ]
 +-------------------------+-------------------------+------------------------+
 ] Data Rate (Mbps)        ] Media                   ] Distance (m)           ]
 +-------------------------+-------------------------+------------------------+
 ] 16                      ] Type 1                  ] 145                    ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] Type 1                  ] 375                    ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] Type 1                  ] 200*                   ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] Type 3                  ] 100                    ]
 +-------------------------+-------------------------+------------------------+
 ] NOTE:   * With any Type 3 lobes on main ring                               ]
 +----------------------------------------------------------------------------+
 Lobe distance requirements in Figure 48 under heading "5.1.1.2.3  Cabling" are
 independent of the type of LAM (that is, ICS or RJ45) and number of LAMs
 installed.
 NOTE:  Lobe length is longer than the normal recommendation because the PI
 adapter reclocks and retransmits the incoming signal, thus acting as a
 repeater.

 +----------------------------------------------------------------------------+
 ] Figure 49. Ring Segment Drive Distance (Media Type 1 or Equivalent)        ]
 +-------------------------+-------------------------+------------------------+
 ] Data Rate (Mbps)        ] Temperature (C)         ] Distance (m)           ]
 +-------------------------+-------------------------+------------------------+
 ] 16                      ] < 60                    ] 200                    ]
 +-------------------------+-------------------------+------------------------+
 ] 16                      ] < 80                    ] 180                    ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] < 60                    ] 400                    ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] < 80                    ] 385                    ]
 +-------------------------+-------------------------+------------------------+
 ] 4                       ] < 80                    ] 300*                   ]
 +-------------------------+-------------------------+------------------------+
 ] NOTE:   * With any Type 3 lobes on main ring                               ]
 +----------------------------------------------------------------------------+
 The ring segment drive distances in Figure 49 under heading "5.1.1.2.3
 Cabling" are the maximum distances supported between IBM 8230s when there is
 no intervening equipment. Paired repeaters inserted between 8230s would
 obviously increase the distances, passive equipment would reduce it.  For
 further information, refer to the IBM TOKEN RING INTRODUCTION AND PLANNING
 GUIDE.
 For definitions of Type 1 (shielded twisted pair) and Type 3 (unshielded
 twisted pair) cable consult IBM CABLING SYSTEM TECHNICAL INTERFACE
 SPECIFICATION.
 The 8230 fiber distances are identical to the IBM 8219/8220 requirements as
 specified in IBM TOKEN-RING NETWORK INTRODUCTION AND PLANNING GUIDE.

 5.1.1.2.4  Reconfiguration:  The IBM 8230 provides automatic ring
 reconfiguration when it detects a ring fault.  In that case the 8230 executes
 an automatic recovery, that is, it bypasses the failing portion of the ring
 segment or the failing 8230.  The word fault means in this case a "hard
 error".  The IBM 8230 does not take action for soft errors.  However, under
 control of the IBM LAN Network Manager, a user can reconfigure the 8230 in
 order to isolate the source of soft errors.  The following new commands are
 available for IBM LAN Network Manager directed recovery:
 o   Wrap/unwrap RI/RO
 o   Disable/enable lobe
 o   Disable/enable LAM.
 The base for automatic ring configuration are the 3 MAC addresses PI,PO and S
 of the 8230.  PO and S are located on the ring-out (RO) side of the 8230, PI
 is on the ring-in (RI) side.  The 8230 can always wrap its 80 lobes to the
 working portion of the ring.
 The 8230 has the direct control over all ring insertion relays.  This includes
 the relays allowing ring stations and Lobe Attachment Modules to attach to the
 ring.  These relays are used to configure the broken part of the ring out of
 the active ring path.
 In order to follow a sample reconfiguration, reference should be made to
 Figure 50 under heading "5.1.1.2.4  Reconfiguration" for a ring installation
 consisting of four IBM 8230s.
 -------------------------------------------------------------------------------

         *----------------------*        *----------------------*
         ]                      ]        ]                      ]
         ]  PO    i i i i    PI ]        ]  PO    i i i i    PI ]
         ]  ]     ] ] ] ]    ]  ]        ]  ]     ] ] ] ]    ]  ]
  *---<--+----------------------+----<---+----------------------+---<--*
  ]      ]                      ]        ]                      ]      ]
  ]    ]                                                          ]    ]
  ]    ]                                                          ]    ]
  ]    ] *----------------------*        *----------------------* ]    ]
  ]    ] ]     IBM 8230 "C"     ]        ]     IBM 8230 "D"     ] ]    ]
  ]    ] ]                  S   ]        ]                  S   ] ]    ]
  ]    ] ]                  ]   ]        ]                  ]   ] ]    ]
  ]    *-+----------------------+---X--<-+----------------------+-*    ]
  ]      ]                      ]        ]                      ]      ]
  ]    RI]                      ]RO    RI]                      ]RO    ]
  ]      ]                      ]        ]                      ]      ]
  *--->--+----------------------+->-X----+----------------------+--->--*
         ]  ]       ] ] ]    ]  ]        ]  ]       ] ] ]    ]  ]
         ]  PI      i i i    PO ]        ]  PI      i i i    PO ]
         ]                      ]        ]                      ]
         *----------------------*        *----------------------*

                S  = 8230 MAC address on backup path
                PI = 8230 MAC address on primary path (RI side)
                PO = 8230 MAC address on primary path (RO side)
                i  = ring station inserted on 8230

 -------------------------------------------------------------------------------
 Figure 50. Ring Cut at X
 If there is an external fault between station "C" and " station "D", that is,
 the cable is broken, the following will happen:
 1.  Ring is cut at X.
 2.  PI "D" beacons, showing NAUN as PO "C", with a beacon type 2 (beacon type
     X'0002' - signal loss error).  MAC address S "C" also beacons on the
     back-up path.
 3.  PO "D" changes the beacon of PI "D" to a beacon type 1 (beacon type
     X'0001' - recovery mode set).
 4.  All MAC addresses in 8230 "B" and "A" are in beacon repeat mode for both
     paths.
 5.  "C" sees type 1 beacon from PO "D", knows his MAC address S is beaconing
     and therefore wraps RO "C" using relays Y (see Figure 47 under heading
     "5.1.1.2.1  Hardware Description").  The situation is now as in Figure 51
     under heading "5.1.1.2.4  Reconfiguration".
 -------------------------------------------------------------------------------

  ]    ]                                                          ]    ]
  V    A                                                          V    A
  ]    ]                                                          ]    ]
  ]    ]                                                          ]    ]
  ]    ] *----------------------*        *----------------------* ]    ]
  ]    ] ]     IBM 8230 "C"     ]        ]     IBM 8230 "D"     ] ]    ]
  ]    ] ]                    S ]        ]                  S   ] ]    ]
  ]    ] ]                    ] ]        ]                  ]   ] ]    ]
  ]    *-+----------------* *---+-- X  --+----------------------+-*    ]
  ]      ]                ] ]   ]        ]                      ]      ]
  ]    RI]                ] ]   ]RO    RI]                      ]RO    ]
  ]      ]                ] ]   ]        ]                      ]      ]
  *--->--+----------------* *---+-- X  --+----------------------+--->--*
         ]  ]   ] ] ]   ]       ]        ]  ]       ] ] ]    ]  ]
         ]  PI  i i i   PO      ]        ]  PI      i i i    PO ]
         ]                      ]        ]                      ]
         *----------------------*        *----------------------*
 -------------------------------------------------------------------------------
 Figure 51. 8230 "C" wraps RO
 6.  Because of the wrap at RO of 8230 "C", the beacon of PO "D" will be seen
     at S of 8230 "D". 8230s A and B are still present, just not shown.
 7.  S "D" recognizes PO "D" address in PO "D" beacon.
 8.  8230 "D" wraps RI and RO, using relays X and Z (see Figure 47 under
     heading "5.1.1.2.1  Hardware Description" ). The situation is now shown in
     Figure 52 under heading "5.1.1.2.4  Reconfiguration".
 -------------------------------------------------------------------------------

  ]    ]                                                          ]    ]
  V    A                                                          V    A
  ]    ]                                                          ]    ]
  ]    ]                                                          ]    ]
  ]    ] *----------------------*        *----------------------* ]    ]
  ]    ] ]     IBM 8230 "C"     ]        ]     IBM 8230 "D"     ] ]    ]
  ]    ] ]                    S ]        ]            S         ] ]    ]
  ]    ] ]                    ] ]        ]            ]         ] ]    ]
  ]    *-+----------------* *---+-- X  --+----* *--------* *----+-*    ]
  ]      ]                ] ]   ]        ]    ] ]        ] ]    ]      ]
  ]    RI]                ] ]   ]RO    RI]    ] ]        ] ]    ]RO    ]
  ]      ]                ] ]   ]        ]    ] ]        ] ]    ]      ]
  *--->--+----------------* *---+-- X  --+----* *--------*
 *----+--->--*
         ]  ]   ] ] ]   ]       ]        ]  ]       ] ] ]    ]  ]
         ]  PI  i i i   PO      ]        ]  PI      i i i    PO ]
         ]                      ]        ]                      ]
         *----------------------*        *----------------------*
 -------------------------------------------------------------------------------
 Figure 52. Wrap RO, Wrap RI/RO
 9.  PO "D" sees his own beacon, knows that the ring is fixed and starts the
     monitor contention process.
 10. S "D" checks the internal ring, LAMs and lobes of 8230 "D".  If there is
     no fault within this ring, then it unwraps RO "D", by using relay Z (see
     Figure 47 under heading "5.1.1.2.1  Hardware Description"). Figure 53
     under heading "5.1.1.2.4  Reconfiguration" shows the recovered ring, with
     all stations active.
 -------------------------------------------------------------------------------

  ]    ]                                                          ]    ]
  V    A                                                          V    A
  ]    ]                                                          ]    ]
  ]    ]                                                          ]    ]
  ]    ] *----------------------*        *----------------------* ]    ]
  ]    ] ]     IBM 8230 "C"     ]        ]     IBM 8230 "D"     ] ]    ]
  ]    ] ]                    S ]        ]            S         ] ]    ]
  ]    ] ]                    ] ]        ]            ]         ] ]    ]
  ]    *-+----------------* *---+-- X  --+----* *---------------+-*    ]
  ]      ]                ] ]   ]        ]    ] ]               ]      ]
  ]    RI]                ] ]   ]RO    RI]    ] ]               ]RO    ]
  ]      ]                ] ]   ]        ]    ] ]               ]      ]
  *--->--+----------------* *---+-- X  --+----* *---------------+--->--*
         ]  ]   ] ] ]   ]       ]        ]  ]       ] ] ]    ]  ]
         ]  PI  i i i   PO      ]        ]  PI      i i i    PO ]
         ]                      ]        ]                      ]
         *----------------------*        *----------------------*
 -------------------------------------------------------------------------------
 Figure 53. Wrap RO, Wrap RI. Broken cable isolated from ring path
 11. S "C" and PI "D" continue monitoring the broken segment.
 12. When it is repaired, S "C" and PI "D" will trigger their respective 8230
     to unwrap RO and RI, thus finally completing all the ring paths.

 5.1.1.2.5  Summary:  The IBM 8230 Controlled Access Unit, with its associated
 Lobe Access Modules provides advanced capability over the unpowered IBM 8228
 Multi-Station Access Unit.
 In conjunction with the IBM LAN Station Manager V1.0, and the IBM LAN Network
 Manager, it enables secure asset and access protection, such that unauthorized
 stations do not connect to the token-ring.
 By means of its internal circuitry and intelligence, it is able to provide
 high levels of ring recovery for situations that, without the 8230, would
 normally require manual intervention. It is also able to accomplish ring
 re-configuration at speed, hence reducing the implications of fault isolation
 on the applications that are running on LAN-attached stations.
 Because of the pluggability of the ring-in and ring-out modules, the IBM 8230
 is adaptable to the changing cabling needs of the customer.

 5.1.1.2.6  Device Attachment Cards:  Any device attachment hardware component,
 for any IBM token-ring attachable device, is complemented by a software and/or
 microcode component.  The combined components implement the IEEE 802.5 and
 IEEE 802.2 LAN standards and optionally, additional LAN management function.
 Whether all of the LLC level code is supplied in the software component or as
 microcode on a particular token-ring adapter card depends on the type of
 attaching device.

 5.1.1.3  Repeaters and Converters
 The distance travelled by a token before regeneration of the signal is limited
 by the attenuation characteristics of the medium.  The adapters of active
 token-ring devices provide regeneration whether or not the device has data of
 its own to send.  In some cases the signal must be maintained over longer
 stretches of cable where stations cannot be placed.  In these cases a special
 device called a REPEATER may be used to provide the regeneration.
 Only copper wire without repeaters may be used in a LOBE, that is the wire
 between the LAN station in the office and a multistation access unit port in
 the wiring closet.
 When longer distances are encountered between wiring closets (INTER-WIRING
 CLOSET CONNECTIONS), active repeaters or converters may be applied.  They are
 used to amplify and re-synchronize the signal, thus extending the maximum
 distance allowed between multistation access units in remote and wiring
 closets.
 The distance by which a repeater extends the transmitted signal is measured
 from the repeater to the next signal driving point.  This could be another
 repeater (as they can be connected in series) or a ring station.
 IBM offers three stand-alone repeaters/converters to provide signal
 regeneration over copper or fiber cables between wiring closets, as well as
 the IBM 8230 Controlled Access Unit which has integrated repeater/converter
 function.
 A major consideration in locating repeaters or converters is the distance the
 signal must be driven in the event cable on the main path fails or is removed,
 since the backup path, which is usually considerably longer than the main
 path, will then be used.
 For copper wiring between wiring closets, 8218 Copper Repeaters or the IBM
 8230 Controlled Access Unit may be installed to provide the necessary signal
 regeneration.  For several reasons a fiber cable may be used between wiring
 closets, for which a pair of 8219 Optical Fiber Repeaters, 8220 Optical Fiber
 Converters or the IBM 8230 Controlled Access Unit may be installed to convert
 electrical signals to/from light pulses.
 A pair of IBM 8220 Fiber Converters or the IBM 8230 Controlled Access Unit
 actively participate in the token passing protocol, thereby supporting
 automatic monitoring of both paths and automatic recovery from some types of
 error.  The other repeater devices, the IBM 8218 Copper Repeater and the IBM
 8219 Fiber Repeater, are simpler components of the physical cabling and do not
 implement MAC layer functions.
 Repeaters and converters contribute to accumulated phase jitter(13 under
 heading "5.1.1.3  Repeaters and Converters") since they amplify and regenerate
 the signal as any LAN station does.

 ---Footnote---
 (13) Every time a signal is amplified and regenerated, a small amount of
 additional phase distortion is introduced. This accumulated effect of phase
 distortion is referred to as phase jitter.
 --------------

 Therefore, repeaters and converters must be included when considering the
 maximum number of devices supported for any given cable type on a single ring.

 5.1.1.4  IBM 8218 Copper Repeater
 Figure 54 under heading "5.1.1.4  IBM 8218 Copper Repeater" represents a
 Copper Repeater (8218).  It is an active component used to cover longer
 copper-wired distances between wiring closets.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                        *-------------------*
 ]                        ]                   ]
 ]                        ]  o  POWER ON      ]
 ]                        ]  o  DATA ERROR    ]
 ]                        ]                   ]
 ]                        ]   *-------* RI    ]
 ]                        ]   ]   )   ]       ]
 ]                        ]   ]   )   ]       ]
 ]                   -----------> )   ]       ]
 ]                   -----------> )   ]       ]
 ]                        ]   *-------*       ]
 ]                        ]                   ]
 ]                        ]   *-------* RO    ]
 ]                        ]   ]   (   ]       ]
 ]                        ]   ]   (   ]       ]
 ]                        ]   ]   ( -------------->
 ]                        ]   ]   ( -------------->
 ]                        ]   *-------*       ]
 ]                        ]                   ]
 ]                        *-------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 54. The 8218 Copper Repeater
 The IBM 8218 Copper Repeater operates only at 4 Mbps.  When used with Type 1
 cable, the maximum distance between two Wiring Closets can be increased to 770
 meters.  With Type 9 cable, the maximum distance is about 500 meters.
 Intermediate 8228 Multistation Access Units are allowed between pairs of 8218
 Copper Repeaters. The actual placement of 8218s depends upon the result of
 design guidelines, documented in IBM TOKEN-RING NETWORK INTRODUCTION AND
 PLANNING GUIDE.  This manual also contains the rules and tables required to
 plan and verify a physical token-ring installation based on IBM Cabling System
 components.
 In the 8218, only the main path entering the ring in (RI) connector is
 amplified and retimed.  Therefore 8218s must be installed in multiple pairs
 (minimum four 8218s) to provide signal symmetry and recovery capability via
 the backup path.
 A sample illustration of 8218 Copper Repeaters without intermediate 8228
 Multistation Access Units, Figure 55 under heading "5.1.1.4  IBM 8218 Copper
 Repeater", shows why two pairs of 8218s are required to maintain full backup
 path capability.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                         oooooooooooooo//ooooooooooooooo
 ]            Patch Panel  o*------------//-------------*o  Patch Panel
 ]           *-------------o]-*                       *-]o-------------*
 ]           ]             o] ]                       ] ]o             ]
 ]           ]             **----*                 *----**             ]
 ]           ]             **oooo]                 ]oooo**             ]
 ]           ]                ] o]                 ]o ]                ]
 ]           ]                ] o]                 ]o ]                ]
 ]           ]                ] o]                 ]o ]                ]
 ]           ]                ] o]                 ]o ]                ]
 ]           ]                ] o]                 ]o ]                ]
 ]           *----------------* \/(S3)         (S2)\/ *----------------*
 ]                  8228 #1     /\                 /\        8228 #2
 ]           *----------------* ]o                 o] *----------------*
 ]           ]           RO **] ]o                 o] ]** RI           ]
 ]           ]              **] ]o                 o] ]**              ]
 ]           *--------------]o* ]o                 o] *o]--------------*
 ]         *----------------*o  ]o                 o]  o*---------*
 ]         ]oooooooooooooooooo  ]o                 o]  ooooooooooo]
 ]         ]o                   ]o                 o]    (S1)    o]
 ]         ]o                   ]o                 o]  *--\/--*  o]
 ]         ]o  8218's           ]o                 o]  ]*-/\-*]  o]
 ]         ]o(R1)  (R4)         ]o                 o]  ]]    ]]  o]
 ]         ]o*--*  *--*         ]o                 o] *]]*  *]]* o]
 ]         ]oo**]RI]**----------*o                 o] ]**]RI]**] o]
 ]         *--**]  ]**oooooooooooo                 o] ]**]  ]**] o]
 ]           ]  ]  ]  ]                            o] ]  ]  ]  ] o]
 ]           ]**]RO]**]                            o*--**]RO]**ooo]
 ]           ]**]  ]**]                            oooo**]  ]**---*
 ]           *]o*  *]o*                               *--*  *--*
 ]            ]o(S4)]o                                (R3)  (R2)
 ]            ]oo\/-*o                                  8218's
 ]            *--/\ooo
 ]
 ]                           oo\/--   yellow cross-over
 ]                           --/\oo   patch cable
 ]                           ------   primary path (red/green)
 ]                           oooooo   backup path  (orange/black)
 +------------------------------------------------------------------------------
 Figure 55. 8218 Copper Repeater Installation
 For convenience, the 8218 Copper Repeaters have been identified (from left to
 right) as: R1, R4, R3, R2.  Cross-over patch cables have been numbered S1, S2,
 S3, S4 (from right to left).
 The primary path leaving the multistation access unit ring-out on the left
 side is normally amplified by R1.  Repeater R2 is required at the other end
 for signal symmetry.
 To provide proper amplification of the backup path signal by R3, a cross-over
 patch cable (S1) is used to swap the ring in and ring out wire pairs entering
 R2 (only the primary pair (red/green) entering the 8218 Ring-In would normally
 be amplified).  In this way, the signal on the backup path will be amplified
 by Repeater R3.
 Before the signal travels back between the wiring closets, the primary and
 backup signals must be restored (on the red/green and orange/black pairs
 respectively) by cross-over patch cable S2.
 The amplification of the backup signal by R3 requires another repeater (R4) at
 the other end.  At the Ring In of R4 the backup signal must arrive on the
 red/green pair.  Therefore cross-over cable S3 is required.
 Finally, after leaving R4, the backup signal is put back on the orange/black
 pair by cross-over cable S4.

 5.1.1.5  IBM 8219 Optical Fiber Repeater
 The IBM 8219 Optical Fiber Repeater extends the effective drive distance
 between wiring closets up to two kilometers using Type 5 cable (containing two
 100/140 micron optical fibers).  Each IBM 8219 provides a standard 4-wire data
 connector for the incoming or outgoing copper cable and two optical connectors
 (marked "receive" and "transmit") for the optical fiber connections as
 illustrated in Figure 56 under heading "5.1.1.5  IBM 8219 Optical Fiber
 Repeater".
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                                *-------------------*
 ]                                ]                   ]
 ]                                ]  o  POWER ON      ]
 ]                                ]  o  LOW SIGNAL    ]
 ]                                ]  o  LOW LIGHT     ]
 ]                                ]                   ]
 ]                                ]                   ]
 ]                                ]  o  RECEIVE       ]
 ]                                ]                   ]
 ]                                ]  o  TRANSMIT      ]
 ]                                ]                   ]
 ]                                ]                   ]
 ]                                ]    *------*       ]
 ]                                ]    ]  ()  ]       ]
 ]                                ]    ]  ()  ]       ]
 ]                                ]    ]  ()  ]       ]
 ]                                ]    ]  ()  ]       ]
 ]                                ]    *------*       ]
 ]                                ]                   ]
 ]                                *-------------------*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 56. 8219 Optical Fiber Repeater
 Other fiber sizes supported are 50/125, 62.5/125 and 85/125.  Like the IBM
 8218 Copper Repeater, the 8219 operates only at 4 Mbps.
 An important advantage of installing fiber cable between wiring closets is
 that the optical signal is virtually immune from outside interference. Optical
 media should be considered for outdoor connections or where cabling must pass
 through electrically noisy areas.
 Use of fiber may also be a consideration to simplify coexistence with and/or
 migration to FDDI LANs in installations with foreseeable high bandwidth
 requirements.
 For more information on the use and installation of fiber optic cabling with
 current IBM products, refer to IBM TOKEN-RING NETWORK - OPTICAL FIBER CABLE
 OPTIONS
 Only the signal carried in the primary path (the red/green wire pair in the
 data connector) is transmitted via the transmit connector of one 8219 and
 received at the receive connector of the other 8219.  The optical signal
 entering the receive connector is converted back to electrical pulses on the
 backup copper wire pair (orange/black).
 These considerations are illustrated in the 8219 Fiber Repeater installation
 in Figure 57 under heading "5.1.1.5  IBM 8219 Optical Fiber Repeater".
 +------------------------------------------------------------------------------
 ]
 ]
 ]                         *-------------//--------------*
 ]            Patch Panel  ]     inter-closet fiber      ]  Patch Panel
 ]           *-------------]--*                       *--]-------------*
 ]           ]            *-* ]          <--          ] *-*            ]
 ]           ]            ]o-----* ---- orange --- *-----o]            ]
 ]           ]            ]o-----] ---- black ---- ]-----o]            ]
 ]           ]            *-* ]  ]       -->       ]  ] *-*            ]
 ]           ]                ]  ]                 ]  ]                ]
 ]           ]                ]  ]                 ]  ]                ]
 ]           ]                ]  ]                 ]  ]                ]
 ]           ]                ]  ]                 ]  ]                ]
 ]           *----------------*  ]                 ]  *----------------*
 ]                  8228         ]                 ]         8228
 ]           *----------------*  ]                 ]  *----------------*
 ]           ]           RO **]  ]                 ]  ]** RI           ]
 ]           ]              **]  ]                 ]  ]**              ]
 ]           *--------------]]*  ]                 ]  *]]--------------*
 ]         *----------------*]   ]                 ]   ]*---\/-----*
 ]         ]*----------------*   ]                 ]   *----/\----*]
 ]         ]]                    ]                 ]              ]] Yellow
 ]         ]]                    ]                 ]              ]] cross-
 ]         ]] 8219               ]                 ]         8219 ]] over
 ]         ]]                    ]                 ]              ]] patch
 ]         ]] *--*               ]                 ]         *--* ]] cable
 ]         ]] ]Ro--* <-orange    ]                 ]black->*--oR] ]]
 ]         ]] ]  ] ]-------------*                 *-------] ]  ] ]]
 ]         ]] ]To--* black->                       <-orange*--oT] ]]
 ]         ]] ]  ]                                           ]  ] ]]
 ]         ]*--**]                                           ]**--*]
 ]         *---**]                                           ]**---*
 ]            *--*                                           *--*
 ]
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 57. 8219 Optical Fiber Repeater Installation
 Because they use only copper connectors, intermediate 8228 Multistation Access
 Units cannot be positioned between paired 8219 Optical Fiber Repeaters.
 This diagram also shows that only one pair of 8219 Fiber Repeaters is required
 to provide a connection between wiring closets with full backup capabilities.
 Note that only one yellow cross-over patch cable is required compared to the
 four cables required by the 8218 example described earlier.
 When the primary signal enters the left 8219 on the red/green copper pair, it
 will be transmitted as an optical signal on the black fiber.  On the right
 side, the black fiber is connected to the receive connector of the second 8219
 where the signal is converted and sent out on the orange/black copper pair.
 Therefore, after leaving the right 8219, a cross-over cable is applied to put
 the primary signal back on the red/green copper pair.
 In backup situations, the signal will be wrapped at the two 8228 access units.
 Consequently the cross-over cable will swap the backup signal to the red/green
 copper wire pair as it leaves the ring-in of the right multistation access
 unit.  Since the backup signal enters the right 8219 on the red/green pair, it
 will be transmitted as an optical signal on the orange fiber. On the left
 side, the orange fiber enters the receive connector of the 8219.  The optical
 light pulses will be converted back to electrical signals and sent out on the
 orange/black copper pair.  This direction is correct for the backup signal as
 it enters the ring-out of the left multistation access unit.

 5.1.1.6  IBM 8220 Optical Fiber Converter
 The 8220 Optical Fiber Converter operates in a token-passing ring to extend
 the distance between multistation access units in separate wiring closets up
 to two kilometers when operating at either 16 Mbps or at 4 Mbps.
 The 8220 Optical Fiber Converter, unlike the 8218 Copper Repeater or 8219
 Optical Fiber Repeater, participates in the token passing ring protocols,
 enabling it to provide error detection and automatic recovery functions in
 some circumstances.  As this implies, each 8220 Optical Fiber Converter has a
 unique individual MAC address to support this capability.
 The 8220 Fiber Optical Repeater has one token-ring media data connector to
 connect the 8220 to the ring in or ring out position of an 8228 Multistation
 Access Unit, two optical connectors (marked "receive" and "transmit") as shown
 in Figure 58 under heading "5.1.1.6  IBM 8220 Optical Fiber Converter" to
 connect to the fiber cables.
 +------------------------------------------------------------------------------
 ]
 ]
 ]
 ]                        *-------------------*
 ]                        ]                   ]
 ]                        ]  o  Power On      ]
 ]                        ]  o  Insert        ]
 ]                        ]  o  E1 Error      ]
 ]                        ]  o  E2 Error      ]
 ]                        ]                   ]
 ]                        ]  !   4 / 16 Mbps  ]
 ]                        ]  !  RI / RO       ]
 ]                        ]                   ]
 ]                        ]  o  RECEIVE       ]
 ]                        ]                   ]
 ]                        ]  o  TRANSMIT      ]
 ]                        ]                   ]
 ]                        ]    *------*       ]
 ]                        ]    ]  ()  ]       ]
 ]                        ]    ]  ()  ]       ]
 ]                        ]    ]  ()  ]       ]
 ]                        ]    ]  ()  ]       ]
 ]                        ]    *------*       ]
 ]                        ]                   ]
 ]                        *-------------------*
 ]
 ]
 ]
 ]o   The Insert LED is on when the 8220 is inserted.
 ]o   E1 and E2 Error LEDs indicate internal and external errors
 ]    respectively.
 ]o   The 4 Mbps/16 Mbps switch enables the 8220 to operate at the
 ]    installation-specified rate.
 ]o   The Ring-In/Ring-Out switch indicates the 8220 operating mode as
 ]    either Upstream (RI) or Downstream (RO).
 +------------------------------------------------------------------------------
 Figure 58. 8220 Optical Fiber Converter
 Apart from offering two operational data rates, 4 MBPS and 16 MBPS, the 8220
 Optical Fiber Converter also has two operational states, WRAP state and
 INSERTED state.
 o   In "wrap" state, the 8220 is not operational.  It is physically and
     logically NOT-INSERTED into the ring.  Due to internal wrapping, a
     fiber-connected pair of 8220 Optical Fiber Converters form a "closed
     ring", allowing self-test diagnostics to execute automatically.  IBM 8220
     Fiber Converters can be removed from and reinserted into a ring like other
     token-ring stations.
 o   In "inserted" state, the 8220 is physically and logically INSERTED in both
     the main and backup paths of the ring, transmitting additional 8220 unique
     frames as well as IEEE 802.5 MAC PROTOCOL (non-early-token-release)
     frames.
 The 8220 Optical Fiber Converter can, by means of the RI/RO switch, be set
 into either of the following operational modes:  UPSTREAM (Ring-In) or
 DOWNSTREAM (Ring-Out).
 A pair of IBM 8220 Optical Fiber Converters connected as shown in diagram
 Figure 59 under heading "5.1.1.6  IBM 8220 Optical Fiber Converter" is called
 a 8220 FIBER OPTICAL CONVERTER SUBSYSTEM.  Both converters are referred to as
 PARTNERS within the 8220 Subsystem protocols.
 -------------------------------------------------------------------------------

  8228/8230                                    8228/8230
  Access                                       Access
  Unit                                         Unit
  ---------*                                   *---------
           ]                                   ]
       RO] ]   Upstream            Downstream  ] ]RI
         ] ]   *------*             *------*   ] ]
  -------+-*   ] 8220 ]             ] 8220 ]   *-+-------
         ]     ]      ]             ]      ]     ]
         ]     ]    Tx]-------------]Rx    ]     ]
         ]     ]      ]             ]      ]     ]
         *-----]    Rx]-------------]Tx    ]-----*
           A   ]      ]             ]      ]   A
           ]   *------*             *------*   ]
  Normal---*   Switched             Switched   *---Yellow
  Black         to RI                to RO         X-over
  Patch cable                                      cable

 -------------------------------------------------------------------------------
 Figure 59. Cabling an IBM 8220
 In this diagram:
 o   The upstream (left) converter is connected to the ring-out position of an
     8228 Multistation Access Unit.  Logically, the upstream converter
     participates in the ring traffic carried in the main path.

     Inversely, the downstream converter is connected to the ring-in position
     of the next 8228 Multistation Access Unit.  Logically, the downstream
     converter participates in the ring traffic carried in the backup path.
 o   The upstream converter provides the control function within the 8220
     subsystem; the downstream converter follows the control function provided
     by the upstream converter.
 o   If a loss of power or failure occurs within the scope of the 8220
     subsystem, the 8220 pair will automatically de-insert from the ring and
     wrap the main ring to the backup ring at each end of the subsystem, thus
     maintaining the operation of the ring.  This is shown schematically in
     Figure 60 under heading "5.1.1.6  IBM 8220 Optical Fiber Converter". As
     soon as the optical fiber cable is repaired, the 8220 subsystem will
     return to normal operation.
 o   An 8220 Optical Fiber Converter can be defined as a CRITICAL RESOURCE to
     the IBM LAN Manager V2 or IBM LAN Network Manager
 o   The downstream 8220 continuously monitors the condition of the backup ring
     so that a potential failure in the backup ring can be identified and
     corrected by operations personnel before the ring is needed for backup
     operation.  This is accomplished by the adapter on the backup path sending
     a Downstream Converter Presence LLC frame to the functional address of LAN
     Manager every 60 seconds.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                              Primary Ring
 ]*-----------------------------------<----------------------------------*
 ]] *--------------------------------->--------------------------------* ]
 ]] ]                           Backup Ring                            ] ]
 ]] ]                                                                  ] ]
 ]] ] *----------------------**---* fiber *---**---------------------* ] ]
 ]] ] ]RI     MSAU 1       RO]]   ] cable ]   ]]RI     MSAU 2      RO] ] ]
 ]] ] ]*---------<----------*]] *----//-----* ]]*---------<---------*] ] ]
 ]] ] ]]***------>---------*]]] *----//-----* ]]]***------>------***]] ] ]
 ]] ] *]]]]--------**------]]*]   ] break ]   ]*]]]]---**--------]]]]* ] ]
 ]] *--*]]]        ]]      ]] ]RI ]       ] RO] ]]]]   ]]        ]]]*--* ]
 ]*-----*]]        ]]      ]*-<-* ]       ] *-<-*]]]   ]]        ]]*-----*
 ]       ]]        ]]      *-->-* ]       ] *->--*]]   ]]        ]]
 ]      *--*      *--*        *---*       *---*  *--* *--*      *--*
 ]      ]S1]      ]S2]                           ]S3] ]S4]      ]S5]
 ]      *--*      *--*        8220         8220  *--* *--*      *--*
 ]                          Upstream     Downstream
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 60. 8220 Subsystem - Automatic Wrap to Backup Ring
 For additional installation considerations and the use of cross-over patch
 cables, refer to the 8219 installation shown in Figure 57 under heading
 "5.1.1.5  IBM 8219 Optical Fiber Repeater".

 5.1.1.6.1  Summary:  The IBM Cabling System offers cable types and components
 to implement general purpose structured wiring for data communications. It
 also allows, within specified limitations, use of existing telephone twisted
 pair wire for transmission of digital data.
 The structured wiring approach implemented by the IBM Cabling System very well
 suits the cabling requirements of the IBM Token-Ring Network, both at 4 Mbps
 and 16 Mbps data rates.  Unshielded telephone twisted pair wire is only
 applicable to 4 Mbps token-ring cabling.  Between multistation access units in
 distant wiring closets, optical fiber cable may be installed.
 Of the three repeaters/converters offered to extend the distance between
 multistation access units in separate wiring closets, the 8220 Optical Fiber
 Converter may frequently provide the most desirable solution. It is the only
 repeater/converter device supporting both 4 Mbps and 16 Mbps data rates
 between wiring closets, and is currently the only device that implements
 automatic recovery for cable failures between wiring closets (since it
 actively participates in the IEEE 802.5 MAC protocols).  The IBM 8230
 Controlled Access Unit, with its integrated repeaters/converters changes the
 picture, and, because it is an active device, can offer superior function and
 recovery capability.

 5.1.2  IBM Token-Ring Network Devices

 5.1.2.1.1  Workstation Adapters:  The original IBM Token-Ring Network Adapter,
 announced in 1985 and often referred to as Token-Ring Adapter I, has been
 withdrawn from marketing.
 IBM Personal Computers and the IBM Personal System/2 Model 30, subsequently
 referred to as Family 1 workstations, can be attached to the IBM Token-Ring
 Network through the IBM TOKEN-RING NETWORK ADAPTER II at a data rate of 4
 Mbps.  The IBM 16/4 TOKEN-RING NETWORK ADAPTER offers a 16 Mbps / 4 Mbps
 switchable token-ring attachment for the same Family 1 devices. This adapter
 has now been superseded by the IBM 16/4 TOKEN-RING NETWORK ADAPTER ENHANCED.
 All other IBM Personal System/2 models, equipped with the Micro Channel bus
 and subsequently referred to as Family 2 workstations, can be attached to the
 IBM Token-Ring Network through the IBM TOKEN-RING NETWORK ADAPTER/A at a data
 rate of 4 Mbps or through the IBM 16/4 TOKEN-RING NETWORK ADAPTER/A to either
 a 16 Mbps or 4 Mbps token-ring LAN. As with the Family 1 workstations, this
 16/4 switchable adapter has been superseded by the IBM 16/4 TOKEN-RING NETWORK
 ADAPTER ENHANCED.
 When attached to a 16 Mbps token-ring LAN using the proper Family 1 or Family
 2 adapter card, the IEEE 802.5 protocol implementation provides the early
 token release option.
 Special token-ring adapters are available for both Family 1 and Family 2 PCs
 and PS/2s (14 under heading "5.1.2.1.1  Workstation Adapters")

 ---Footnote---
 (14) PC and PS/2 are registered trademarks of the International Business
 Machines Corporation.
 --------------

 to support the IBM Token-Ring Network Trace and Performance Program,
 respectively the IBM 16/4 TOKEN-RING NETWORK TRACE AND PERFORMANCE ADAPTER and
 the IBM 16/4 TOKEN-RING NETWORK TRACE AND PERFORMANCE ADAPTER /A.  The IBM
 Token-Ring Network Trace and Performance facilities are discussed in "9.7 IBM
 Token-Ring Network Trace and Performance Facilities."
 The RT/PC provides also a 4 Mbps attachment to an IEEE 802.5 LAN.

 5.1.2.1.2  Adapter Support Interface for Token-Ring Attached Workstations:
 IBM LAN SUPPORT PROGRAM: The adapter support interface between the
 workstation's processor and any token-ring adapter card is included in the IBM
 LAN SUPPORT PROGRAM.  More details on the other functions of this product are
 provided in "5.6 IBM LAN Support Program."  One significant function with
 respect to adapter support however is to provide access to memory locations on
 a token-ring adapter card from which the workstation processor can retrieve
 received information or to which it must place data for transmission. These
 memory locations reside in an area of the adapter card called SHARED RAM.
 All currently offered 4 Mbps IBM Token-Ring Network adapters have a Shared RAM
 of 16 Kbytes. The 16/4 Mbps switchable adapters have a shared RAM of 64 KB
 which can be divided into four 16 KB pages.  All or part of these memory pages
 may be used by system software.  A technique called RAM PAGING, supported by
 the IBM LAN Support Program, permits use of the entire 16 or 64 KB shared RAM
 memory while requiring only 16 KB in the PC or PS/2 memory.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                            PS/2 Memory                     ]
 ]                                      *----------------------*              ]
 ]                                      ]                      ]              ]
 ]      64 KB Shared RAM                /                      /              ]
 ]  *----------------------*            ]                      ]              ]
 ]  ] 512 Bytes - reserved ]            ]                      ]              ]
 ]  ]----------------------]            ]----------------------] ---------    ]
 ]  ]                      ]            ]                      ]     ]        ]
 ]  ] 15.5 Kbytes - Page 4 ] <---*      ]                      ]     ]        ]
 ]  ]                      ]     ]      ]                      ]     ]        ]
 ]  ]----------------------]     ]      ]----------------------]     ]        ]
 ]  ]                      ]     ]      ]/////                /]   128 KB     ]
 ]  ]  16 Kbytes - Page 3  ] <---+----> ]///   16 Kbytes    ///]   adapter    ]
 ]  ]                      ]     ]      ]/                /////]   mapping    ]
 ]  ]----------------------]     ]      ]----------------------]     ]        ]
 ]  ]                      ]     ]      ]                      ]     ]        ]
 ]  ]  16 Kbytes - Page 2  ] <---]      ]                      ]     ]        ]
 ]  ]                      ]     ]      ]                      ]     ]        ]
 ]  ]----------------------*     ]      ]----------------------* ---------    ]
 ]  ]     (8 KB - 1B)      ]     ]      ]                      ]              ]
 ]  ]- 16 Kbytes - Page 1 -] <---*      ]                      ]              ]
 ]  ]     (8 KB - 1A)      ]            /                      /              ]
 ]  *----------------------*            ]                      ]              ]
 ]                                      *----------------------*              ]
 ]                                                                            ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 61. RAM Paging
 In general, a larger shared RAM size allows larger frames to be transmitted,
 (up to a maximum 4 KB frame size on a 4 Mbps token-ring adapter with 16 KB
 shared RAM versus 16 KB maximum frame size on a 16/4 Mbps token-ring adapter
 with 64 KB shared RAM.  Use of larger frame sizes provides the potential for
 improved ring utilization.   Larger shared RAM memory size also enables
 support for more (up to 254) link stations (see "3.2.2 Logical Link Control
 Sublayer").
 Figure 62 under heading "5.1.2.1.2  Adapter Support Interface for Token-Ring
 Attached Workstations" shows the default shared RAM utilization as implemented
 by the IBM LAN Support Program for a 16 KB shared RAM size.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]      Ring Station A                              Ring Station B            ]
 ]                                                                            ]
 ]     16 KB Shared RAM                            16 KB Shared RAM           ]
 ]*------------------------*                  *------------------------*      ]
 ]] Work Area - 1588 bytes ]                  ] Work Area - 1588 bytes ]      ]
 ]]------------------------]                  ]------------------------]      ]
 ]] SAPs      n x 64 bytes ]                  ] SAPs      n x 64 bytes ]      ]
 ]]------------------------]                  ]------------------------]      ]
 ]] Link Stations          ]                  ] Link Stations          ]      ]
 ]]          m x 144 bytes ]                  ]          m x 144 bytes ]      ]
 ]]------------------------]                  ]------------------------]      ]
 ]] Transmit Buffers       ]                  ] Transmit Buffers       ]      ]
 ]]------------------------] Frame (p bytes)  ]------------------------]      ]
 ]]    Receive Buffers     ] ---------------> ]    Receive Buffers     ]      ]
 ]]                        ] <--------------- ]                        ]      ]
 ]] - - - - - - - - - - - -]  Frame (q bytes) ] - - - - - - - - - - - -]      ]
 ]]        unused          ]                  ]        unused          ]      ]
 ]*------------------------*                  *------------------------*      ]
 ]                                                                            ]
 ]     Receive Buffers                          Transmit Buffers              ]
 ]    <--- r bytes --->                       <------- t bytes -------->      ]
 ]    ]               ]                       ]                        ]      ]
 ]  *-----------------*                       *------------------------*      ]
 ]  ]                                                                         ]
 ]  *>]               ]                                                       ]
 ]  *-----------------*   Number of    ]Transmit Buffers]Receive Buffer       ]
 ]  ]                     Link Stations]Number      Size]    Size             ]
 ]  *>]               ]   -------------+----------------+--------------       ]
 ]  *-----------------*       1 - 32   ]   2        2040]     280             ]
 ]  ]                        33 - 48   ]   2        1048]     280             ]
 ]  *>.................      49 - 64   ]   1        1048]     280             ]
 ]  *-                         > 64    ]   1         600]     144             ]
 ]  ]                                                                         ]
 ]  *<]               ]                                                       ]
 ]    *---------------*                                                       ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 62. Shared RAM Utilization
 The maximum frame length is determined as the smallest of either the
 transmission buffer size or half the number of receive buffers times the
 receive buffer size.  The number of receive buffers is a function of the
 number of SAPs and the number of link stations.  A realistic maximum number of
 link stations is 64 for a token-ring adapter with 16KB RAM.
 Larger frame sizes can be obtained by reducing the number of required SAPs and
 link stations.  Default parameters supplied by the IBM LAN Support Program
 should be evaluated with respect to the LAN applications used by the
 workstation to ensure that neither too few or too many link stations, SAPs,
 sessions, and outstanding commands are defined.
 Receive Buffers are chained to accommodate at least twice the transmit frame
 size.   This prevents overrun for incoming frames received faster than can be
 handled by the receiving adapter and processor.
 Currently IBM Token-Ring Network adapters can be equipped with a REMOTE
 INITIAL PROGRAM LOAD (RIPL) feature, consisting of a pluggable EPROM. This
 feature allows a token-ring attached device to obtain a bootstrap program from
 a remote LAN RIPL server at power-on time, rather than supplying its own
 startup code.  For additional information, see "8.1 IBM PC LAN Program V1.2."

 5.1.3  IBM PC Network (Broadband) Components
 The IBM PC Network (Broadband) consists of a set of IBM products that allow
 the interconnection of IBM PCs to form a local area network in a tree
 topology.
 The IBM PC Network (Broadband) components are:
 o   IBM PC Network Adapter cards
 o   IBM PC Network Translator Unit and Splitter or other commercial
     translators used with customer cabling
 o   IBM PC Network (Broadband) cabling components:
     -   IBM Base Expander
     -   IBM Short Distance Kit
     -   IBM Medium Distance Kit
     -   IBM Long Distance Kit
 o   Adapter Support software (the IBM LAN Support Program).
 Figure 63 under heading "5.1.3  IBM PC Network (Broadband) Components" shows
 the structure of the IBM PC Network (Broadband) local area network. Using IBM
 components the network can support up to 72 workstations, at a distance of up
 to 305 meters (1000 ft.) from the translator unit.
 +------------------------------------------------------------------------------
 ]
 ]
 ]              8 nodes direct
 ]                  *-----* 8-way      *-----* short
 ]                  ]oooo ] splitter   ]oooo ] distance
 ]            *-----] oooo]      *-----] oooo] kit
 ]            ]     *-----*      ]     *-----*
 ]*------*    ]            0.3 m ]                     *-----*
 ]]      ]   *-*   *-------------*  122 meters         ]oooo ]
 ]]      ]---]C]---]oooo ]-----------------------------] oooo]
 ]]      ]   *-*   ] oooo]-------* medium distance kit *-----*
 ]*------*         *-----*       ]                                  *-----*
 ]Translator       Base          ]            244 meters            ]oooo ]
 ]Unit             Expander      *----------------------------------] oooo]
 ]                                            long distance kit     *-----*
 ]C = directional coupler
 ]kit-to-node: max. 61 m
 ]
 ]                  *------------------------------------------------*
 ]                  ] IBM cable    ] Custom Network ] Custom Network ]
 ]                  ] kits and IBM ] and IBM        ] and commercial ]
 ]                  ] translator   ] translator     ] translator     ]
 ]*-----------------+--------------+----------------+----------------]
 ]]multiple channels]     no       ]     no         ]     yes        ]
 ]]distance (radius)]    305 m     ]    305 m       ]     5 Km       ]
 ]]number of nodes  ]     72       ]    256         ]     1000       ]
 ]*------------------------------------------------------------------*
 ]
 +------------------------------------------------------------------------------
 Figure 63. IBM PC Network (Broadband) Components
 The number of PCs that can be attached to the network, and the distance that
 they can be from the translator unit can be increased by using non-IBM
 equipment. For example, using the IBM translator and non-IBM expander(s) and
 cabling,  256 PCs can be supported.  Using a third-party translator, up to
 1000 workstations may be attached while the network radius may be increased to
 about 5 kilometers.

 5.1.3.1.1  PC Network (Broadband) Adapters:  PCs or PS/2s are attached to the
 network through a PC Network (Broadband) Adapter card.  Several adapters are
 available: the original IBM PC Network Adapter and a number of second
 generation adapters including the IBM PC Network Adapter II for Family 1
 devices, the IBM PC Network Adapter II/A for Family 2 devices, and PC Network
 Adapters for both families of devices operating at different transmit and
 receive channels (Frequency 2 and Frequency 3 adapters).
 IBM PC NETWORK ADAPTER

           The original PC Network adapter fits only Family 1 devices.  It uses
           Radio Frequency (RF) channels T13 and J from the mid-split channel
           range (offering 17 channel pairs, with a 168.25 MHz offset).
           Card-mounted Intel 82586 and 80188 processors provide the CSMA/CD
           support as well as support for a higher level protocol, NETBIOS, in
           ROM on the adapter.
 IBM PC NETWORK ADAPTER II

           This second generation adapter for Family 1 devices uses the same RF
           channels T13 and J as the original PC Network adapter.  The adapter
           uses an Intel 82588 LAN controller chip to provide framing and media
           access functions, but does not provide any higher-layer protocol in
           ROM.
 IBM PC NETWORK ADAPTER II/A

           This adapter is equivalent to the PC Network Adapter II but is
           designed for Family 2 devices with smaller card forms and Micro
           Channel support.
 IBM PC NETWORK ADAPTER II, II/A FREQUENCY 2

           These adapters for Family 1 and Family 2 devices respectively offer
           the same features as the IBM PC Network Adapters II and II/A, except
           that they transmit and receive on different channels frequencies.
           Frequency 2 Adapters use RF channels 2' and O from the high-split
           broadband range (30 channel pairs with a 192.25 MHz offset).
           High-split is commonly used in a manufacturing environment, where
           these adapters can coexist (not communicate) with other devices
           attached to the same broadband medium, for example, MAP 2.1
           adapters.
 IBM PC NETWORK ADAPTER II, II/A FREQUENCY 3

           Again these adapters are functionally equivalent to the other second
           generation (II) PC Network adapters, except that these adapters
           operate on high-split RF channels 3' and P.
 Figure 64 under heading "5.1.3.1.1  PC Network (Broadband) Adapters" lists the
 part numbers of all current PC Network (Broadband) adapters.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]*----------------------------------------------------------------------*    ]
 ]] IBM PC Network (Broadband) Adapters       ] Part    / Feat.] 04/1989 ]    ]
 ]] (AFE)                                     ] Number  / Code ] Part No.]    ]
 ]]-------------------------------------------+----------------+---------]    ]
 ]] IBM PC Network Adapter                    ] 6450213 / 0213 ]   N/A   ]    ]
 ]]                                           ]                ]         ]    ]
 ]] IBM PC Network Adapter II                 ] 1501220 / 1220 ] 25F8279 ]    ]
 ]] IBM PC Network Adapter II - Frequency 2   ] 96X5645 / 5645 ] 25F8282 ]    ]
 ]] IBM PC Network Adapter II - Frequency 3   ] 96X5646 / 5646 ] 25F8285 ]    ]
 ]]                                           ]                ]         ]    ]
 ]] IBM PC Network Adapter II/A               ] 1501222 / 1222 ] 25F8278 ]    ]
 ]] IBM PC Network Adapter II/A - Frequency 2 ] 96X5647 / 5647 ] 25F8281 ]    ]
 ]] IBM PC Network Adapter II/A - Frequency 3 ] 96X5648 / 5648 ] 25F8284 ]    ]
 ]*----------------------------------------------------------------------*    ]
 ]                                                                            ]
 ]*----------------------------------------------------------------------*    ]
 ]] IBM PC Network (Broadband) Adapters       ] Part    / Feat.] 04/1989 ]    ]
 ]] (EMEA)                                    ] Number  / Code ] Part No.]    ]
 ]]-------------------------------------------+----------------+---------]    ]
 ]] IBM PC Network Adapter                    ] 6450213 / 0213 ]   N/A   ]    ]
 ]]                                           ]                ]         ]    ]
 ]] IBM PC Network Adapter II                 ] 1501220 / 1220 ]         ]    ]
 ]] IBM PC Network Adapter II - Frequency 2   ] 96X5645 / 5645 ]         ]    ]
 ]] IBM PC Network Adapter II - Frequency 3   ] 96X5646 / 5646 ]         ]    ]
 ]]                                           ]                ]         ]    ]
 ]] IBM PC Network Adapter II/A               ] 1501222 / 1222 ] 25F8280 ]    ]
 ]] IBM PC Network Adapter II/A - Frequency 2 ] 96X5647 / 5647 ] 25F8283 ]    ]
 ]] IBM PC Network Adapter II/A - Frequency 3 ] 96X5648 / 5648 ] 25F8286 ]    ]
 ]*----------------------------------------------------------------------*    ]
 +----------------------------------------------------------------------------+
 Figure 64. IBM PC Network (Broadband) Adapters
 There is no communications path between PC Network (Broadband) adapters
 operating on different channel pairs, even if they are attached to the same
 common medium.  All adapters operating on the same transmit and receive
 channels form one LAN segment, physically and logically separated from
 adapters operating at a different channel pair. Connectivity can only be
 provided through LAN segment interconnection such as the PC Network Bridge
 Program, see "6.6.3 IBM PC Network Bridge Program" for more details.
 All second generation PC Network Adapters require the IBM LAN SUPPORT PROGRAM
 to provide the adapter support interface and make the LAN protocols accessible
 to applications.  The original IBM PC Network Adapter, having NETBIOS in Read
 Only Memory (ROM) on the adapter card, contains its own interface and gives
 access to the LAN for application programs through NETBIOS.  However, not all
 NETBIOS commands are supported and no other application interfaces are
 supported.  The IEEE 802.2 LLC interface or other higher layer protocols (for
 example, SNA protocols) are not available unless the IBM LAN Support Program
 is used to bypass the ROM NETBIOS, and provide the same interfaces as for the
 second generation adapters. A more detailed discussion about LAN Support
 Program and coexistence considerations is presented in "5.6 IBM LAN Support
 Program."

 5.1.3.1.2  IBM Translator Unit and Splitter:  The IBM PC Network (Broadband)
 Translator Unit provides broadband frequency translation for a passive IBM PC
 Network (Broadband).  One translator is required for each network.  The IBM
 Translator Unit provides only single channel frequency shift between modulated
 signals transmitted at a 50.75 MHz center frequency and a receive channel with
 a 219 MHz center frequency. Only this mid-split channel pair is recognized by
 the IBM Translator Unit. All other signals are ignored.  Third party
 translators are required to operate a PC Network (Broadband) LAN at the
 high-split frequencies used by the PC Network (Broadband) Frequency 2 or 3
 adapters.
 The IBM PC Network Translator Unit is packaged together with a directional
 coupler and an 8-way splitter, supporting direct connection for eight nodes up
 to 61 meters (200 feet) from the splitter.  See Figure 63 under heading "5.1.3
 IBM PC Network (Broadband) Components" for an illustration of the components.
 The translator supports a single channel-pair, data-only network of 256 nodes
 if custom cabling is used rather than the pre-cut cabling kits.  The nodes (PC
 or PS/2 workstations) can be up to 305 meters (1000 feet) away from the
 translator unit.  Replacement of the IBM Translator Unit by a more
 sophisticated device is required if broadband multiple channel capability is
 desired.  In this case however, the calibration and tuning by a CATV
 specialist should planned for both initial installation and on-going
 maintenance.
 The directional coupler also has a port for attaching an IBM PC Network
 (Broadband) Base Expander.

 5.1.3.1.3  IBM PC Network (Broadband) Base Expander:  The Base Expander allows
 for the attachment of up to eight additional cabling kits. Three different
 kits are available: the IBM short distance kit, medium distance kit, and long
 distance kit.
 Workstations cannot be connected directly to the base expander unit.  They
 must be connected via one of the cabling kits.  By using the base expander and
 the cabling kits an additional 64 PCs (up to a maximum of 72 workstations) can
 be attached to the network.

 5.1.3.1.4  Cabling Kits:  Because of the sensitivity of the transmitters and
 receivers in radio frequency broadband transmission to cables that are either
 very short or very long, the use of pre-defined cable lengths minimizes and in
 most cases eliminates the effort and cost of recalibrating the frequencies.
 o   The IBM PC Network (Broadband) Short Distance Kit connects directly to the
     base expander and allows up to eight nodes to be connected.  Cables are
     available with lengths up to 61 meters (200 feet) to connect a PC or PS/2
     to a splitter.
 o   The IBM PC Network (Broadband) Medium Distance Kit allows for the
     attachment of a splitter at 122 meters (400 feet) from the base expander.
     Hence, the maximum distance a node can be away from the translator is 183
     meters (600 feet).
 o   The IBM PC Network (Broadband) Long Distance Kit consists of a cable that
     is 244 meters (800 feet) in length and a splitter.  PCs or PS/2's attached
     to the splitter can be up to 305 meters (1000 feet) away from the
     translator unit.

 5.1.4  IBM PC Network (Broadband) Interfaces

 5.1.4.1.1  IBM PC Network Medium Access Control:  The IBM PC Network Adapter
 implements a CSMA/CD protocol like that of the IEEE 802.3 standard, although
 it does not provide an IEEE 802.3 interface.  Apart from transmission speed,
 technique, and network topology used, the second generation PC Network
 Adapters (II) are similar to the IEEE 802.3 standard with respect to the
 CSMA/CD protocol and support for the IEEE 802.2 standard interface.  Therefore
 the way stations access the medium, the MAC frame structure, and the interface
 provided by the adapters conform to the description of CSMA/CD LANs provided
 in "2.2.1 Basic CSMA/CD Concepts."

 5.1.4.1.2  IEEE 802.2 Logical Link Control Support:  For the second generation
 adapter cards, the IEEE 802.2 layer support and interface is provided by the
 IBM LAN Support Program.  The IBM LAN Support Program optionally provides the
 same support and interfaces for the IBM PC Network Adapter as it bypasses and
 replaces the NETBIOS ROM with its own software modules.
 The IBM LAN Support Program optionally provides a session level NETBIOS
 interface, running on top of the IEEE 802.2 LLC module.  See "5.6 IBM LAN
 Support Program" for more information.

 5.1.4.1.3  Higher Layer Protocol Support:  NETBIOS is a proprietary
 higher-layer protocol providing session connection support on top of the IEEE
 802.2 interface through service access point value X'F0.
 SNA service access points provide the required interfaces between the PC
 Network (Broadband) LAN and SNA path control via service access point value
 X'04 or multiple of X'04.
 The 8232 LAN Channel Station provides the same connectivity to IBM PC Network
 attached workstations as to IBM Token-Ring Network attached workstations, with
 one exception. A non-SNA IBM host, running AIX/370, is not accessible from a
 PC Network device and this environment is not supported.  The 8232 LAN Channel
 station may be equipped with any Family 1, second generation PC Network
 adapters (Frequency 1, 2 or 3).

 5.2  IBM PC Network Baseband
 The IBM PC Network Baseband is designed to be a low-cost local area network
 for IBM PCs and PS/2's. The network uses baseband transmission at 2 Mbps. The
 medium access protocol is, as for IBM PC Network Broadband, CSMA/CD.
 The network is made up from a series of segments, each of which is a
 daisy-chain of up to eight workstations.  If the IBM PC Network Baseband
 consists of eight or fewer workstations, the topology can remain as a single
 daisy-chain, Figure 65 under heading "5.2  IBM PC Network Baseband" with a
 maximum length of 61 meters (200 feet). Such a topology is illustrated in
 Figure 65 under heading "5.2  IBM PC Network Baseband" .
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]    <------------------ 61 meters (8 stations) -------------------->        ]
 ]                                                                            ]
 ] *-*  *--------------*   *--------------*   *---------//---------*  *-*     ]
 ] ]T]  ]              ]   ]              ]   ]                    ]  ]W]     ]
 ]*-------*          *-------*          *-------*                *-------*    ]
 ]]       ]          ]       ]          ]       ]                ]       ]    ]
 ]]       ]          ]       ]          ]       ]                ]       ]    ]
 ]]       ]          ]       ]          ]       ]                ]       ]    ]
 ]*-------*          *-------*          *-------*                *-------*    ]
 ]                                                                            ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 65. IBM PC Network Baseband - Single Segment Daisy-Chain
 There is a wrap plug at one end of the chain while the other end is terminated
 with a terminator plug.
 If more than eight workstations are required in the network the IBM 5173 PC
 Network Baseband Extender must be used. With the PC Network Baseband Extender,
 up to 80 workstations can be attached to the network in a multiple daisy-chain
 configuration, illustrated in Figure 66 under heading "5.2  IBM PC Network
 Baseband".
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]*-----*<---------------------- 122 meters ------------------------->        ]
 ]]     ]                                                                     ]
 ]] 5  I]------------*  *----------*  *----------*  *-------//-------* *-*    ]
 ]] 1  I]            ]  ]          ]  ]          ]  ]                ] ]T]    ]
 ]] 7  I]          *------*      *------*      *------*            *------*   ]
 ]] 3  I]          ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]]    I]----*     ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]]    I]    ]     ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]] E  I]    ]     *------*      *------*      *------*            *------*   ]
 ]] X  I]    ]                                                                ]
 ]] T  I]    *-------*  *----------*  *----------*  *-------//-------* *-*    ]
 ]] E  I]            ]  ]          ]  ]          ]  ]                ] ]T]    ]
 ]] N   ]-*        *------*      *------*      *------*            *------*   ]
 ]] D  O]T]        ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]] E   ]-*        ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]] R   ]-*        ]      ]      ]      ]      ]      ]            ]      ]   ]
 ]]    O]W]        *------*      *------*      *------*            *------*   ]
 ]]     ]-*                                                                   ]
 ]*-----*                                                                     ]
 ]                                                                            ]
 ]       I = IN Ports  (10)        T = Terminator plug                        ]
 ]       O = OUT Ports  (2)        W = Wrap plug                              ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 66. IBM PC Network Baseband - Multiple Daisy-Chain Segments
 If more than 80 workstations are required, then the IBM 5173 Baseband
 extenders can themselves be daisy-chained together, up to a maximum of ten.
 The largest PC Network Baseband configuration can thus be 800 workstations.

 5.2.1  PC Network Baseband Components

 5.2.1.1.1  IBM PC Network Baseband Adapters:  Two adapters are available for
 the IBM PC Network Baseband: the IBM PC Network Baseband Adapter for the
 Family 1 workstations, and the IBM PC Network Baseband Adapter/A for Family 2
 PS/2s.  Instead of a radio frequency modem as on IBM PC Network (Broadband)
 adapters, they use a transceiver on the adapter.
 The adapters together with the IBM LAN Support Program provide CSMA/CD medium
 access control, the IEEE 802.2 LLC protocol and an open interface to the
 logical link control services.  Because the data rate (2 Mbps), topology and
 electrical characteristics deviate from a Standard IEEE 802.3 CSMA/CD LAN
 using twisted pair media, the IBM PC Network Baseband does not fully conform
 to the international standard.
 The adapter cards allow up to eight LAN stations to be daisy-chained together,
 with an overall length of up to 61 meters (200 feet).  The length of the chain
 is dependent on the number of workstations in the chain.  For example if there
 are only two workstations in the chain (the minimum number) the distance
 between the two workstations can be up to 91.4 m (300 feet).  Any distance
 between two workstations in a chain is allowed as long as the total distance
 between the first and last node does not exceed the recommended maxima listed
 below:

          *------------------------------*
          ] NUMBER OF ] MAXIMUM          ]
          ] NODES     ] DISTANCES        ]
          ]-----------+------------------]
          ]   2       ] 91.4 m  (300 ft) ]
          ]-----------+------------------]
          ]   3       ] 83.8 m  (275 ft) ]
          ]-----------+------------------]
          ]   4       ] 76.0 m  (250 ft) ]
          ]-----------+------------------]
          ]   5       ] 68.5 m  (225 ft) ]
          ]-----------+------------------]
          ]   6       ] 68.5 m  (225 ft) ]
          ]-----------+------------------]
          ]   7       ] 61.0 m  (200 ft) ]
          ]-----------+------------------]
          ]   8       ] 61.0 m  (200 ft) ]
          *------------------------------*

 Figure 67. Length of a Single Segment Daisy-Chain
 In any chain like the example illustrated in Figure 65 under heading "5.2  IBM
 PC Network Baseband", the workstation at one end must have a terminator plug
 and the station at the other end must have a wrap plug.
 The adapter card ROM contains self-test diagnostics that are run when the
 adapter is powered on. These diagnostics help a user to identify adapter
 failures without a diagnostic diskette or problem determination manuals.

 5.2.1.1.2  IBM 5173 PC Network Baseband Extender:  The IBM 5173 PC Network
 Baseband Extender is used to expand the IBM PC Network Baseband from eight to
 eight hundred nodes. The PC Network Baseband Extender has ten ports, each able
 to support a chain of maximum eight LAN stations.  Each chain attached to the
 PC Network Baseband Extender has a maximum length of 121.92 m (400 ft).  This
 distance is measured from the extender to the last workstation in the chain.
 The IBM 5173 PC Network Baseband Extender is designed for continuous,
 unattended operation, therefore it does not have an on/off switch. There are
 also no option switches or jumpers. The PC Network Baseband Extender has one
 indicator light which is illuminated when the power is on.  The indicator can
 either be red or green, depending on whether an error was detected by the
 self-test circuitry. The self-test function is initiated by depressing a
 button on the front panel.
 The PC Network Baseband Extender contains a 12-watt universal power supply.
 It has 10 "IN" ports on the front panel for connecting chains of PCs to the
 extender, and two "OUT" ports as shown in Figure 66 under heading "5.2  IBM PC
 Network Baseband". The OUT ports are used for daisy-chaining the extenders
 together, up to the maximum of ten. A wrap plug must be inserted in an OUT
 port of the first extender, and a terminator plug in an OUT port of the last
 extender.  A terminator plug must also be inserted into the adapter card of
 the last workstation of each chain attached to the extender.
 Cabling is not supplied with the extender, nor with the PC Network Baseband
 Adapter cards, but must be ordered separately.

 5.2.1.1.3  PC Network Baseband Cabling and Accessories:  The IBM PC Network
 Baseband uses twisted pair wiring for interconnecting workstations.  Three
 adapter cables are offered to provide connector compatibility with different
 types of building wiring.  Each cable connects to the workstation adapter with
 a modular telephone jack (J11). The other end provides either another modular
 jack or a different connector type to support daisy chaining of workstations,
 or connection wall jacks or sockets.
 THE IBM PC NETWORK BASEBAND ADAPTER CABLE (1501229) is shielded twisted pair
 cable with modular telephone connectors at each end. It is designed to
 serially connect the IBM PC Network Baseband Adapter or the IBM PC Network
 Baseband Adapter/A to other workstations in a daisy-chain fashion, or to
 connect a workstation to the IBM 5173 PC Network Baseband Extender.
 THE IBM PC NETWORK BASEBAND GENERAL PURPOSE CABLE (1501228)  is a shielded
 twisted pair cable
  connecting an IBM PC Network Baseband Adapter or IBM PC Network Baseband
 Adapter/A to a non-modular telephone socket.  It has the modular connector on
 one end while the other end is made for the older screw terminal blocks.
 THE IBM CABLING SYSTEM PC NETWORK BASEBAND CABLE (150227) is a shielded
 twisted pair cable connecting the IBM PC Network Baseband Adapter, IBM PC
 Network Baseband Adapter/A, or the IBM 5173 PC Network Baseband Extender (with
 a modular telephone connector) to the data connector wall jack or data
 connector distribution panel when using the IBM Cabling System.
 Each baseband cable is 7.6 m (25 ft) in length. Several of these cables can be
 joined together to obtain cable lengths greater than 7.6 meters, or users can
 make their own cables to the lengths they require.  With care to prevent
 electromagnetic interference, unshielded twisted pair wire, meeting the IBM
 Cabling System Type 3 specifications, may also be applied.
 THE IBM PC NETWORK BASEBAND EXTENDER RACK MOUNT KIT (1501226) attaches to the
 IBM 5173 PC Network Baseband Extender to allow it to be rack mounted in a
 standard 19 inch rack.

 5.2.2  PC Network Baseband Interfaces

 5.2.2.1.1  Medium Access Control support:  The IBM PC Network Baseband Adapter
 and IBM PC Network Baseband Adapter/A, combined with the adapter support
 software of the IBM LAN Support Program, implement CSMA/CD access method
 protocols functional equivalent to the IEEE 802.3.  (Refer to "2.2.1 Basic
 CSMA/CD Concepts" for details on the protocol, and to "5.6 IBM LAN Support
 Program" for additional information on LAN Support Program.)

 5.2.2.1.2  PC Network Baseband Bridging:  The IBM PC Network Baseband network
 can be bridged to either the IBM PC Broadband Network or the IBM Token-Ring
 Network by using the IBM PC Network Bridge Program. Thus workstations attached
 to the PC Baseband network can access stations attached to either of the other
 networks, token-ring connected host gateways etc..  More details on the IBM PC
 Network Bridge can be found in "6.6.3 IBM PC Network Bridge Program" .

 5.2.2.1.3  IEEE 802.2 LLC and Higher Layer Support:  The IEEE 802.2 layer is
 provided by the IBM LAN Support Program. This program includes the IEEE 802.2
 interface, and optionally provides NETBIOS for higher-layer support.  The IEEE
 802.2 Interface is also required for Advanced Program-to-Program Communication
 (APPC). See section "5.6 IBM LAN Support Program" for more details.

 5.3  Ethernet/IEEE 802.3
 IBM provides support for devices to attach to these LANs.  In October 1990 IBM
 announced the Personal System/2 Adapter/A for Ethernet Networks.  This adapter
 attaches to both Ethernet Version 2 and IEEE 802.3 networks.

 5.3.1  Workstations
 Support for Ethernet or IEEE 802.3 attachment of IBM PCs and PS2s is provided
 in both the OS/2 and PC/DOS environment. If running the OS/2 Extended Edition
 operating system, Version 1.2, provides the necessary software to enable the
 NETBIOS and IEEE 802.2 logical link control application interfaces.
 If running PC/DOS, then LAN Support Program Version 1.2 is a requirement.
 Further description of this support can be found in "5.6.5 IBM LAN Support
 Program Version 1.2."
 Ethernet/IEEE attachment is also supported by the PC-RT and RISC RS/6000
 processors in the TCP/IP and AIX environments.

 5.3.2  Bridges
 The IBM 8209 LAN Bridge, with Ethernet Adapter Feature, provides a mechanism
 for bridging Ethernet/IEEE 802.3 LAN segments to token-rings.  Further
 information on this product is available in "6.7 IBM 8209 LAN Bridge."

 5.3.3  Gateways
 Direct attachment of IBM gateways to Ethernet/IEEE 802.3 LANs is possible if
 the IBM 8232 or IBM 3172 products are being used.  However, the full range of
 IBM communication gateways can be accessed by Ethernet/IEEE 802.3 workstations
 if an 8209 LAN bridge is inserted in the network to bridge the CSMA/CD segment
 to a token-ring.  These products are discussed in "7.3 Non-SNA Gateways."

 5.4  Industrial LAN

 5.4.1  The 8232 LAN Channel Station and Industrial LAN
 The 8232 may also attach to an industrial LAN.  The supported adapters are the
 INI MP-500 Interface Adapters (15 under heading "5.4.1  The 8232 LAN Channel
 Station and Industrial LAN") implementing MAP 2.1.

 ---Footnote---
 (15) Industrial Networking Inc. (INI) is a joint venture between Ungermann-Bass
 and General Electric, providing communications products for the manufacturing
 environment, today mainly MAP 2.1 implementations.
 --------------

 Because these adapters require both LAN adapter slots in the 8232 PC, only one
 IEEE 802.4 LAN attachment is supported by an IBM 8232 Model 001, and a maximum
 of two IEEE 802.4 LAN attachments or one IEEE 802.4 attachment and two IEEE
 802.3 or IEEE 802.4 attachments are supported by and IBM 8232 Model 002.
 The software requirements are summarized in Figure 68 under heading "5.4.1
 The 8232 LAN Channel Station and Industrial LAN", for both the 8232 LAN
 Channel Station and the IBM System/370 host.

 *---------------------------------------------------------------------*
 ]     8232:  IBM MAP LAN Channel Station Support Program   (5798-FBF) ]
 ]            + IBM PC/DOS Support for Token-Bus Adapter    (5590-TBI) ]
 ]---------------------------------------------------------------------]
 ] IBM non-SNA Host              ] LAN Station                         ]
 ]-------------------------------+-------------------------------------]
 ]                               ]                                     ]
 ] IBM MAP 2.1 Protocol -        ] software support for                ]
 ]     VM Support     (5798-FBG) ]     INI MP-500 MAP Interface Adapter]
 ]                               ]                       (INI 94X4235) ]
 ]                               ]                                     ]
 *---------------------------------------------------------------------*

 Figure 68. 8232 - Software Requirements for MAP 2.1 Support

 5.4.2  Migration to MAP 3.0
 Migration from MAP 2.1 to MAP 3.0 implies both software application as well as
 hardware changes and consequently will require considerable planning.
 To minimize the effort for software migration, MAP 2.1 application programming
 interfaces (API) in the current VM support on System/370 mainframes have been
 designed to be consistent with the MAP 3.0 specifications.
 The MMS API Release 2 and the CASE API Release 1 meet the MAP 3.0 Private
 Communications User API specifications where applicable. Use of these APIs
 will result in fewer programming changes when migrating to MAP 3.0.
 The hardware however will require "significant upgrades", including in most
 cases replacement of the MAP components. Moreover, future MAP 3.0 products for
 workstations are likely to be developed for Family 2 devices, while current
 INI MAP 2.1 adapters support only the Family 1 bus design.

 5.4.3  MAP - SNA Gateway
 Communication between a MAP environment and an SNA network can be provided
 only by a gateway function since both networks cover a full seven-layer
 communications architecture.

 5.4.4  Series/1 and Industrial LAN
 The Series/1 in an industrial LAN environment can act as either a
 communication server or an application server.

 5.4.4.1.1  Communication Server:  The communications server runs on the
 Realtime Programming System/Communications Manager (RPS/CM) operating system.
 Some of the server functions provided are:
 o   Availability of the Series/1 as a directory server for the network
 o   Network management agent support
 o   Host control - that is control of communications with a host system
 o   Terminal control - that is control of communications with downstream
     terminals
 o   Attachment possibilities for System/370 processors.
 With a System/370 processor attached to the Series/1, files can be transferred
 to and from the System/370 using the FTAM (File Transfer, Access and
 Management) program.  Messaging is also supported using the MMFS
 (Manufacturing Message Format Standard) support. This provides a way for
 user-written messaging applications to build and decode standard messages.
 Both FTAM and MMFS are MAP 2.1 Application Layer services (see Figure 35 under
 heading "3.2.1.2.2  Manufacturing Automation Protocol").  MMFS is superseded
 in MAP 3.0 by the Manufacturing Messaging Specifications (MMS).
 The Network Management Agent provides information about the activities in the
 local MAP Communications Server system to the network manager.
 Host control allows a host system, such as TSO, IMS, or CICS to communicate
 with remote 327x terminals, or applications that simulate 327x terminals on a
 MAP network. The MAP network is transparent to the host systems.
 Terminal control allows users of 327x terminals to communicate with remote
 host systems across a MAP network.

 5.4.4.1.2  Application Server:  The Application Server uses the Series/1 Event
 Driven Executive/Communications Facility (EDX/CF) operating system.  The
 application server is used to control intelligent devices and provides the
 following functions:
 o   Network Management Agent services
 o   A subset of directory services
 o   MMFS support
 o   FTAM subset.

 Figure 69 under heading "5.4.4.1.2  Application Server" shows an industrial
 LAN with two Series/1 attachments to the bus using a network interface unit
 (not shown in the figure).
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]    *---------*      *-----------*         *---------*                      ]
 ]    ] Host 1  ]      ]  Host 2   ]         ] Host 3  ]                      ]
 ]    ]         ]      ]           ]         ]         ]                      ]
 ]    ]   OEM   ]      ]System/370 ]         ]   OEM   ]                      ]
 ]    ]         ]      ]-----------]         ]         ]                      ]
 ]    ]         ]      ]FTAM ] MMFS]         ]         ]                      ]
 ]    *---------*      *-----+-----*         *---------*                      ]
 ]         ]                 ]                    ]                           ]
 ]    *---------*       *---------*          *---------*                      ]
 ]    ]Processor]       ]Series/1 ]MCS       ]Processor]                      ]
 ]    *---------*       *---------*          *---------*                      ]
 ]         ]                 ]                    ]                           ]
 ]  ------------------------------------------------------                    ]
 ]                   IEEE 802.4 Token Bus                                     ]
 ]     ----------------------------------------------------                   ]
 ]           ]                    ]                   ]                       ]
 ]      *---------*          *---------*         *---------*                  ]
 ]      ]Processor]       MAS]Series/1 ]         ]Processor]                  ]
 ]      *---------*          *---------*         *---------*                  ]
 ]         ] ] ]                 ] ]                  ]                       ]
 ]       *-------*               ] ]           *--------------*               ]
 ]       ]Welding]           *---------*       ]Assembly Line ]               ]
 ]       ]Devices]           ] Milling ]       *--------------*               ]
 ]       *-------*           ]  Plant  ]                                      ]
 ]                           ]         ]                                      ]
 ]                           *---------*                                      ]
 ]                                                                            ]
 ]                                                                            ]
 ]           MCS = MAP Communication Server                                   ]
 ]           MAS = MAP Application Server                                     ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 69. Industrial LAN - Series/1 Servers

 5.5  TCP/IP
 Although TCP/IP cannot be considered only as a LAN concept or product, the
 acronym will be found many times within this document.  There is also a fair
 sprinkling of TCP/IP application terminology, for instance Telnet. So for
 those readers who are not familiar with it, a very short introduction is
 offered here. For a more in depth tutorial on the subject, the reader is
 recommended to:
 o   TCP/IP TUTORIAL AND TECHNICAL OVERVIEW - GG24-3376-01
 The history of TCP/IP, or TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL can
 be traced back to the 1970's, when the United States Defense Advanced Research
 Projects Agency (DARPA) funded research into the development of a protocol
 suite that would allow networking between computers. The agency, using its
 experimental ARPANET network, introduced the concept of a LAYERED architecture
 long before the International Standards Organization took any interest in
 computer networking. They developed, in conjunction with universities and
 other research organizations, the protocols that have become TCP/IP as is
 known today. In addition, they funded the implementation of TCP/IP under the
 UNIX(**) operating system, and the University of California at Berkeley to
 distribute the code free with the operating system. TCP/IP has rapidly spread
 among universities and research centers, and has become the standard
 communication subsystem for all UNIX connectivity.  The UNIX operating system
 is implemented by IBM as AIX.  In 1983, DARPA demanded that all computers
 wishing to connect to the ARPANET should use TCP/IP. This means that TCP/IP is
 well supported by the various computer manufacturers, and IBM is no exception.

 5.5.1  Structure
 As its name implies, TCP/IP consists of two parts:
 o   The Transmission Control Protocol
 o   And the Internet Protocol.
 TCP/IP also specifies a number of "standard" application functions and
 protocols, that can be used for file transfer, simple messaging and terminal
 login. These, together with the layering are shown in Figure 70 under heading
 "5.5.1  Structure".
 -------------------------------------------------------------------------------

   *-----------------*   *-----------------------------------* *----*
   ]  Applications   ]   ]SMTP]TELNET]FTP]X-Windows]Rexec]NFS] ]SNMP]
   ]-----------------]  *-------------------------------------------]
   ]   Transport     ]  ]              T  C  P                ] UDP ]
   ]-----------------]  ]-------------------------------------------]
   ]  Internetwork   ]  ]                 I  P                      ]
   ]-----------------]  ]-------------------------------------------]
   ]Network Interface]  ]                                           ]
   ]      and        ]  ]IEEE 802.2-X.25-Satellite-Radio-Asynch-SNA ]
   ]   Hardware      ]  ]                                           ]
   *-----------------*  *-------------------------------------------*

 -------------------------------------------------------------------------------
 Figure 70. TCP/IP Architectural Model
 o   APPLICATION

     Is a user process cooperating with another process on the same or a
     different host. Examples include SMTP (Simple Mail Transfer Protocol) and
     FTP (File Transfer Protocol).
 o   TRANSPORT

     Provides for the end-to-end data transfer between applications.  TCP is a
     connection-oriented protocol allowing reliable, acknowledged and sequenced
     interchange of information. There is also a connection-less variant, known
     as the User Datagram Protocol (UDP). UDP provides a less reliable service
     for simpler applications, one of the most important being the Simple
     Network Management Protocol (SNMP).
 o   INTERNETWORK

     Provides the networking image, and shields the higher layers from the
     physical network below it. The IP deals with the routing of the data
     through the network, or when they are interconnected, networks. It does
     not provide for reliability of the underlying network, flow control or
     error recovery. The IP layer is connection-less.
 o   NETWORK INTERFACE

     is the interface to the actual hardware itself. TCP/IP supports a variety
     of physical network types, including IEEE 802.2 Logical Link Control,
     X.25, Packet Radio networks, and even SNA. Nothing is assumed about the
     reliability of the network to provide reliable delivery of data.

 5.5.2  Addressing and Routing
 Computers attached to a TCP/IP network, no matter from what the network is
 physically built, access each other by an INTERNET ADDRESS As the name
 suggests, this function is handled by the IP layer. The address, which may be
 considered as a higher layer address has two parts:
 o   A network address
 o   And a host address.
 Each host computer has a unique address within the network to which it is
 attached. If networks are themselves connected together, then each network
 must have a unique address.
 When networks are connected together, routing devices must be present at the
 points of connection to forward traffic from one network to the other. These
 special computers, Internet Routers, understand the topology of the Internet
 network addressing scheme, and so can forward the data frames towards the
 destination network.  Applications must know to which network/host addresses
 they wish to communicate, or must find out by first interrogating a NAME
 SERVER which will translate a user name, for example "host01" to an Internet
 address.
 However, these Internet addresses do not necessarily bear any relationship to
 the addresses which are understood by layers lower than the IP layer, that is
 within the network interface. IP supports many different network building
 blocks, LANs, X.25 etc., each of which has its own addressing structure. Once
 the message has been routed to the correct network, using the IP address, the
 last router must be able to map the host address portion of the Internet
 address to the lower layer address that will be recognized. This could be a
 LAN MAC address, or an X.121 (if using X.25) address.  For instance, if a
 station is attached to a token-ring, a circulating frame is only copied when
 the destination MAC address in the frame is recognized. The station does not
 analyze the frame, so cannot recognize Internet addresses. So if the MAC
 address is not known to the router, a resolution function must be performed.
 This is the function of the ADDRESS RESOLUTION PROTOCOL (ARP).
 For ARP, when an Internet address needs to be translated into a physical
 address, a special broadcast frame is sent out over the network. Any station
 that recognizes its own Internet address within the frame will reply
 indicating its physical address. The information is kept by the router in its
 ARP CACHE Although the original frame gets discarded, future frames arriving
 for that host will be sent to the correct physical destination, in this case,
 the token-ring MAC address of the TCP/IP station.
 REVERSE ADDRESS RESOLUTION PROTOCOL or RARP works in reverse, much as its name
 suggests.  Perhaps a device, such as a diskless workstation, does not know its
 Internet address when IPL'ed.  It may send a RARP request to a server,
 indicating its physical address, and enquiring as to what its Internet address
 should be set to.

 5.5.3  TCP/IP Applications
 TCP is a peer-to-peer, connection oriented protocol. There are no master/slave
 relations. The applications, however, usually use a server/client model for
 communications.
 A SERVER is an application that offers a service to users, a CLIENT is the
 requestor of that service. An application consists of both a server and a
 client part, which can run on the same or on different systems. Users usually
 invoke the client part of the application, which builds a request for a
 particular service and sends it to the server part of the application, using
 the TCP/IP as a transport vehicle.
 The server receives the request, performs the service, and replies with the
 results to the client. Servers usually can deal with multiple requests at one
 time.
 o   TELNET

     The Telnet protocol provides a standardized interface, through which a
     program on one host (the Telnet client) may access the resources of
     another (the Telnet server) as though the client were a local terminal
     attached to the server. The protocol usually works in a line-by-line mode,
     similar to that used by many asynchronous terminals.  IBM, in its
     implementations of Telnet, has introduced working using 3270 datastream,
     for obvious reasons. This is known as Telnet/3270.
 o   FILE TRANSFER PROTOCOL

     Copying of files from one machine to another is one of the most frequently
     used operations in networking.

     The File Transfer Protocol provides the capability to access files and
     directories on a remote server host.  Files may be transferred in either
     direction between server and client.
 o   X-WINDOWS

     The objective of the X-window protocol is to allow applications to execute
     across several remote systems and to provide the user with a view into
     each system from a single location.
 o   SMTP

     An electronic mail protocol that is used for sending and receiving
     messages across the network.
 o   REXEC/RPC

     These protocols have been developed to allow users and applications on one
     system to invoke procedure and application execution on remote systems in
     the network.
 o   SNMP

     The Simple Network Management protocol is used to communicate management
     information between the network management stations and the agents in the
     network elements. In many ways, the concepts used here are very similar to
     those that have already been discussed in "2.4 LAN Station Management."
     The Internet community are investigating moving this protocol in the
     direction of CMIP in accordance with the ISO approach.
 TCP/IP is supported by IBM in the following environments:
 o   System/370 Virtual Machine (VM) operating system
 o   System/370 Multiple Virtual Storage (MVS) operating system
 o   PC/DOS
 o   OS/2 Extended Edition
 o   AS/400 processor
 o   System/88 processor
 o   AIX for VM S/370
 o   AIX for the PC-RT(6150) and RS/6000 processors.

 5.6  IBM LAN Support Program
 Generally speaking, LAN applications may be developed at different levels
 within the communications architecture, either through standard interfaces or
 through proprietary communications protocol interfaces.
 Some interfaces, although conforming to published standards are system
 interfaces accessible only by a low-level programming language such as IBM
 PC/DOS Macro Assembler, while other interfaces are described as high-level
 Application Programming Language Interfaces (APIs) supported in a high-level
 programming language such as C, COBOL, or Pascal.  Use of system interfaces is
 often limited to systems programming development, where high-level APIs are
 more appropriate for general purpose application implementation.  Selection of
 interfaces to use must take into consideration the degree of product
 sensitivity of the API and the susceptibility of the resulting development to
 subsequent changes in the supporting environment.  In general, users are
 encouraged to use higher-level APIs such as those provided by the emerging
 System Application Architecture.
 In a PC/DOS environment, the IBM LAN Support Program V1.10 provides system
 level interfaces interfaces for all current IBM LAN adapters operating in
 Family 1 or Family 2 devices.  In an OS/2 EE environment, the equivalent
 support for Family 2 device adapters only, is provided by the OS/2 EE
 Communications Manager.
 o   IBM Token-Ring Network Adapter (withdrawn from marketing)
 o   IBM Token-Ring Network Adapter II
 o   IBM Token-Ring Network Adapter /A
 o   IBM 16/4 Token-Ring Network Trace and Performance Adapter
 o   IBM 16/4 Token-Ring Network Trace and Performance Adapter /A
 o   IBM 16/4 Token-Ring Network Adapter
 o   IBM 16/4 Token-Ring Network Adapter /A
 o   IBM 16/4 Token-Ring Network Adapter Enhanced
 o   IBM 16/4 Token-Ring Network Adapter /A Enhanced
 o   IBM PC Network Adapter (withdrawn from marketing)
 o   IBM PC Network Adapter II
 o   IBM PC Network Adapter II/A
 o   IBM PC Network Adapter II Frequency 2
 o   IBM PC Network Adapter II/A Frequency 2
 o   IBM PC Network Adapter II Frequency 3
 o   IBM PC Network Adapter II/A Frequency 3
 o   IBM PC Network Baseband Adapter
 o   IBM PC Network Baseband Adapter /A.

 The IBM LAN Support Program implements IEEE 802.2 logical link control layer
 services and protocols, supporting the standard logical link control Class II
 open interface. Optionally, IBM LAN Support Program provides a NetBIOS
 higher-layer interface for the IBM Token-Ring Network, IBM PC Network
 (Broadband) and IBM PC Network Baseband, and with the announcement of IBM LAN
 Support Program Version 1.2 provides these interfaces to Ethernet Version 2 or
 IEEE 802.3 networks as well.  Support for these two networks was introduced by
 OS/2 Extended Edition in release 1.2 of that product.  The term ETHERAND(*) is
 used by IBM to describe this function in the OS/2 environment. Further
 information can be found on LAN Support Program and Ethernet support in "5.6.5
 IBM LAN Support Program Version 1.2." Application programs can be written
 against the IEEE 802.2 or NetBIOS interfaces.  In addition, a number of other
 higher-layer protocols and interfaces may operate on top of the open LLC
 interface, including IBM's strategic LU 6.2 protocol for program-to-program
 communication.  Such additional higher layer protocols may be provided through
 separate products which use IBM LAN Support Program, for example, APPC/PC for
 LU 6.2 communications.
 NetBIOS is a proprietary but widely implemented higher-level protocol LAN
 interface for workstation applications.  Various applications are available
 which use the NetBIOS interface to communicate across the LAN, for example the
 IBM PC LAN Program 1.3 and IBM PC 3270 Emulation Program Version 3 (Gateway
 and Network Station configurations).
 All the function supplied by the IBM LAN Support Program V1.10 is included in
 the OS/2 Extended Edition 1.1 (trademark of the International Business
 Machines Corporation) Communications Manager. In addition, the LU 6.2
 implementation included in OS/2 Extended Edition Communications Manager has a
 much more convenient programming language interface as well as high-level
 language support (IBM C/2 Compiler and IBM Pascal/2 Compiler). The programming
 interface included in the PC/DOS APPC/PC is limited to IBM PC/DOS Macro
 Assembler.
 Figure 71 under heading "5.6  IBM LAN Support Program" shows the base
 programming interfaces on IBM LANs as introduced above.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]   Interfaces           Protocols                  SNA Layers               ]
 ]                                                                            ]
 ]                                            *----------------------*        ]
 ]                                            ]     Transaction      ]        ]
 ]   LU 6.2 ------------------>*--------*     ]----------------------]        ]
 ]                             ]        ]     ]    Presentation      ]        ]
 ]   NetBIOS -------->*-------*]        ]     ]----------------------]        ]
 ]                    ]       ]] LU 6.2 ]     ]  Data Flow Control   ]        ]
 ]                    ]       ]]        ]     ]---                ---]        ]
 ]                    ]NetBIOS]]        ]     ] Transmission Control ]        ]
 ]                    ]       ]]--------]     ]---                ---]        ]
 ]                    ]       ]] PU 2.1 ]     ]     Path Control     ]        ]
 ]   802.2 ---->*-----------------------]     ]----------------------]        ]
 ]              ]    IEEE 802.2 LLC     ]     ]      Data Link       ]        ]
 ]   MAC -->*---------------------------]     ]       Control        ]        ]
 ]          ]  medium access control    ]     ]----------------------]        ]
 ]          *---------------------------*     ]       Physical       ]        ]
 ]                                            *----------------------*        ]
 ]                                                                            ]
 ]   ---------------------------------------------------------*               ]
 ]   OS/2 EE 1.1 ]          Communications Manager            ]               ]
 ]   ------------+--------------------------------------------]               ]
 ]   PC/DOS      ] APPC/PC ]       LAN Support Program        ]               ]
 ]   ------------+---------+----------------------------------]               ]
 ]   Interfaces  ] LU 6.2  ] NetBIOS ] 802.2 LLC ] Direct MAC ]               ]
 ]   ---------------------------------------------------------*               ]
 ]                                                                            ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 71. IBM LANs - Base Programming Interfaces
 The adapter support program, as provided by the IBM LAN Support Program V1.10
 or as included in the LAN Communications Manager of OS/2 Extended Edition 1.1
 or higher, provides a system application programming interface to the adapter.
 With the use of an adapter support program, a local area network system
 application program assembles a control block containing a command and related
 information for the adapter. Control is passed to the adapter support program
 and the application awaits the results.  In other words, the application
 program passes command control blocks (CCBs) to the adapter support program to
 interface with the adapter.
 Command control blocks are used at the level of the IEEE 802.2 interface and
 the direct (medium access control) interface.
 With the advent of the OS/2 Extended Edition 1.1 LAN Communications Manager,
 two additional, slightly different command control block structures have been
 added to the original CCB as it existed in the IBM LAN Support Program. One
 new CCB is associated with OS/2 1.1's dynamic link routine interface, the
 other one with its device driver interface.
 Applications coded at the MAC level (through the direct interface) are
 confined to the local ring and will not be able to communicate across bridges.
 Additional APIs are offered with various LAN applications, for example, the PC
 3270 Emulation API, the Server/Requester Programming Interface (SRPI),the 3270
 Workstation Program HLLAPI or OS/2's Common Services Interface (CSI).

 5.6.1  Base Programming Interfaces

 5.6.1.1  Open IEEE 802.2 LLC Interface
 An overview of the IEEE 802.2 logical link control sublayer was described in
 "3.2.2 Logical Link Control Sublayer," including the concept of LLC service
 access points to interface between data link control and higher layer protocol
 services.
 Both connectionless or datagram services as well as connection-oriented
 services are included in the standard. The IBM LAN Support Program supports
 both, as Class II operation.  The format of the LLC protocol data unit (LPDU)
 and a list of the service commands/responses is included in "3.2.2.3 LLC
 Protocol Data Unit."

 5.6.1.2  NetBIOS Interface
 NETWORK BASIC INPUT OUTPUT SYSTEM (NetBIOS) is a well-accepted proprietary
 higher-level LAN protocol, providing a session-level programming interface.
 NetBIOS supports a layered communications architecture as shown in Figure 72
 under heading "5.6.1.2  NetBIOS Interface".  Names rather than network
 addresses are used by Netbios applications for session support.  NetBIOS
 support provides services to locate and associate these names with MAC network
 addresses.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]                                                                            ]
 ]         LAN station A                        LAN station B                 ]
 ]                                                                            ]
 ]         ]   NetBIOS    ]                  ]   NetBIOS    ]                 ]
 ]         ]  Interface   ]                  ]  Interface   ]                 ]
 ]         *--------------*                  *--------------*                 ]
 ]         ]   Session    ]<-----Message---->]   Session    ]                 ]
 ]         ]--------------]                  ]--------------]                 ]
 ]         ]  Transport   ]<---Connection--->]  Transport   ]                 ]
 ]         ]--------------]                  ]--------------]                 ]
 ]         ]   Network    ]<-----Packet----->]   Network    ]                 ]
 ]         ]--------------]                  ]--------------]                 ]
 ]         ]    Link      ]<----- LPDU ----->]    Link      ]                 ]
 ]         ]--------------]                  ]--------------]                 ]
 ]         ]  Physical    ]<---------------->]  Physical    ]                 ]
 ]         *--------------*   LAN Physical   *--------------*                 ]
 ]                              Medium                                        ]
 ]                                                                            ]
 ]                    LPDU = LLC protocol data unit                           ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 72. NetBIOS Layer Support
 o   LINK LAYER

     At the Link layer, NetBIOS can use "connectionless" (user datagram) or
     connection-oriented services.  This layer is responsible for the assembly
     of data units, and the delivery of these data units to the physical media
     for transmission.  CRC checking is also performed.
 o   NETWORK LAYER

     The network layer is implemented as a "null" layer.
 o   TRANSPORT LAYER

     At this level, point-to-point connections are created supporting data
     transmission and acknowledgements. Any required flow control or pacing is
     handled at this level.
 o   SESSION LAYER

     Through the session layer, NetBIOS establishes "name" pairs.  A name is an
     identifier for a logical entity in which all session-level communication
     activity is centered.
 The NETBIOS INTERFACE provides an application programming interface offering
 commands for session control, name support, datagram support, and debugging
 facilities.  An overview of the NetBIOS interface and functions is provided
 later of this section. For additional detail and programming support, users
 should refer to the IBM LOCAL AREA NETWORK TECHNICAL REFERENCE.

 5.6.1.2.1.1  NetBIOS Implementations:  Two different versions of NetBIOS,
 including different error codes and transmission sizes, currently exist and
 are incompatible from the standpoint of interoperability.  NetBIOS was
 originally provided in microcode on the IBM PC Network Adapter in Read Only
 Memory (ROM).  Subsequently a superset of the original NetBIOS was implemented
 in the IBM LAN Support Program V1.10, providing equivalent function and
 application interfaces for all IBM LAN-attached workstations under control of
 PC/DOS.
 When, on a IBM PC Network (Broadband), some stations are equipped with the IBM
 PC Network Adapter while others are equipped with second generation PC Network
 adapters, a NetBIOS coexistence problem arises which must be solved to allow
 communication among all PC Network (Broadband) stations.  Two solutions may be
 considered, each with different consequences.  They will be presented in
 section "5.6.2 LAN Support Program Structure."
 Figure 71 under heading "5.6  IBM LAN Support Program" shows the NetBIOS
 module as it is implemented by the IBM LAN Support Program V1.10.  This module
 interfaces to IEEE 802.2 via the X'F0' LLC service access point (see "3.2.2.2
 IEEE 802.2, ISO 8802-2").  NetBIOS provides services supporting (non-SNA)
 peer-to-peer communications.

 5.6.1.2.1.2  The NetBIOS Interface:  The NetBIOS function within each
 workstation maintains a table of names that this node and its session partners
 are known by on the network.  Communications between NetBIOS applications is
 based upon resource names. These names are provided to NetBIOS by the
 application program. A name can be a unique or a group name.  NetBIOS provides
 services to ensure uniqueness of names. If name is in the NetBIOS Name Table,
 a session can be established from this named resource with another named
 resource. NetBIOS maintains up to 254 selectable names plus one permanent node
 name (10 bytes of binary zeros followed by the adapter's burned-in address).
 NetBIOS is operated from an application program through a control block,
 called the NETWORK CONTROL BLOCK (NCB).
 The NetBIOS Interface provides the following services:
 GENERAL CONTROL SERVICES.  which include:
 o   RESET

     In the LAN Support Program implementation, this command aborts all
     sessions, clears both the session and name tables and resets the NetBIOS
     status.  In OS/2 Extended Edition 1.1, this command aborts all sessions
     for that application program process, clears both the session and name
     tables and resets the NetBIOS status.
 o   STATUS

     This command requests the status of either a local or remote NetBIOS
     resource for transfer to the user's program area.
 o   CANCEL

     This command requests that a command associated with a given network
     control block (NCB) be cancelled.
 o   LAN STATUS ALERT

     This command is used by application programs that wish to be notified of
     temporary LAN error conditions that last for over one minute.
 o   UNLINK

     This command is provided only for NetBIOS compatibility.  In the PC
     Network it drops a session for Remote Program Load.  Where the command is
     issued to an adapter that does not support Remote Program Load, the
     command will be treated by the NetBIOS program as a "no-operation".
 NAME SUPPORT SERVICES.  which allow a program to manage user-assigned names or
 identifiers by use of the following commands:
 o   ADD NAME

     To add a new name (up to 16 characters) to the memory resident name table.
 o   ADD GROUP NAME

     A "Group Name" is a mechanism for allowing more than one station to share
     the same resource name.  This enables resources to be defined for
     functions that may exist in multiple workstations in a distributed
     application environment.
 o   DELETE NAME

     To remove a name from the name table.
 o   FIND NAME

     To determine whether a given name is registered on a network adapter.
 SESSION SUPPORT SERVICES.  A "session" is a logical connection between two
 named resources supporting peer-to-peer communications.  When a session has
 been established with another named resource, information can be exchanged
 over the session between the two resources.  This reliable data transfer is
 provided by the SESSION layer.  A program may refer to multiple names and
 therefore sustain multiple sessions between itself and other stations on the
 LAN.
 Command services available to the user to manage the sessions include:
 o   CALL

     This command opens a session with another named resource which has an
     outstanding Listen command.
 o   LISTEN

     This command enables a session to be established between the named
     resource that issues the Listen and any named resource on the LAN which
     issues a Call.
 o   HANG UP

     This command closes a session between two named resources.
 o   SEND

     This command is used to transmit data between two session partners.  The
     maximum MESSAGE size is 64 Kbytes.  To maintain data integrity, the
     session is closed if a Send command fails.
 o   CHAIN SEND

     A Chain Send is equivalent to the Send command, but the message is made up
     of two concatenated buffers (maximum 64 Kbytes in total).
 o   SEND NO ACKNOWLEDGEMENT Like the Send command this command provides a send
     facility, but without requiring a NetBIOS level data acknowledgement.
 o   CHAIN SEND NO ACKNOWLEDGEMENT

     This command is equivalent to the Send No Acknowledgement command, but the
     message is made up of two concatenated buffers (maximum 64 Kbytes in
     total).
 o   RECEIVE

     This command receives data sent over a specified session or over any open
     session.
 o   RECEIVE ANY

     This command receives data sent from any session partner.
 o   SESSION STATUS

     This command will return the status of one or all sessions for a given
     Name.
 DATAGRAM SUPPORT SERVICES provide a connectionless data transmission service.
 That is, when individual unrelated messages (called datagrams) are to be sent,
 it is not always necessary to establish a session between the network
 stations. Messages are just transmitted to a named station or a group of
 stations on the LAN. No error recovery or sequencing is performed and a
 station does not have to acknowledge receiving a frame.  Datagram Support
 Services can be contrasted with the "connection-oriented" services offered by
 the Session Support Services commands.  Data transfer using datagram support
 goes directly to the DATA LINK layer.
 o   SEND DATAGRAM

     Allows an application program to send a datagram to a specific name or
     group name.
 o   SEND BROADCAST DATAGRAM

     Allows an application program to send a datagram to any station which has
     a Receive Broadcast Datagram command outstanding.
 o   RECEIVE DATAGRAM

     A station must use this command to receive datagrams from any name on the
     network that issues a Send Datagram.
 o   RECEIVE BROADCAST DATAGRAM

     A station must use this command to receive datagrams from any name on the
     network that issues a Send Broadcast Datagram.
 DEBUGGING SUPPORT SERVICES

 o   TRACE

     In the IBM LAN Support Program V1.10 and OS/2 EE 1.1 implementations of
     NetBIOS this command has been added to activate and de-activate a trace of
     all the network control blocks (NCBs) issued to NetBIOS by the application
     program and some of the command control blocks (CCBs) issued by NetBIOS.

 5.6.1.3  LU 6.2 Interface
 APPC (Advanced Program to Program Communication) defines a set of
 communication services that enable transaction programs to cooperatively
 execute distributed transactions. APPC function is implemented in an SNA
 protocol called LU Type 6.2.  APPC Transaction Programs (TP), that is
 application programs using the APPC interface, use the LU 6.2 protocols to
 communicate with each other as peers.
 Communication between two APPC programs is known as a "conversation".  A
 conversation flows on an underlying session between two LUs.  When parallel
 sessions are supported between the LUs, multiple conversations can run
 concurrently between two transaction programs.  Parallel sessions are only
 supported for LUs associated with Type 2.1 node devices.
 Products that implement LU 6.2 provide APPC services in different ways. The
 precise definition of these services is independent of any particular product,
 and constitutes part of the architectural definition of LU 6.2.  The services
 are invoked by defined verbs, parameters, and return codes.  A "verb"
 corresponds to a request by a transaction program for some specific service
 from the LU.  As long as a transaction only requests APPC functions supported
 by both systems (peers), a programmer can use the APPC verb syntax to develop
 a distributed application independent of the system it will run on.
 There are two categories of LU 6.2 conversation verbs, BASIC and MAPPED.
 Basic conversation verbs provide a lower-level interface to the LU. These
 verbs have greater privileges and are appropriate for system-oriented
 transaction programs that perform services for other transaction programs.
 Mapped conversation verbs are intended for user-written transaction programs.
 They provide an interface suitable for high level languages.  Conversations
 are called basic or mapped conversations depending on the verbs being used.
 APPC is IBM's strategic architecture for distributed transaction processing,
 and has been implemented in the following products.  These products all
 support APPC mapped conversations:
 o   CICS/VS
 o   AS/400
 o   S/38
 o   System/36
 o   Series/1
 o   PCs, PS/2s  (APPC/PC, OS/2 EE).
 The System Application Architecture (SAA) Common Programming Interface for
 Communications is a published application programming interface that invokes
 the services of APPC and LU 6.2 from high-level languages in various SAA
 environments.  As SAA implementations evolve, it is intended that the defined
 programming interfaces enable users to develop SAA conforming applications
 that can exist in different SAA product environments with greater product
 transparency to both programmers and users.  Although the Common Programming
 Interface for Communications is not yet implemented in all the target
 environments, users can develop APPC applications consistent with the
 published interface to minimize ongoing application changes.

 5.6.1.3.1  APPC/PC:  APPC/PC, available in a PC/DOS environment, provides Type
 2.1 node and/or PU 2.0 and LU 6.2 function to allow transaction programs to be
 written for IBM workstations to communicate with other APPC systems.  These
 systems could be any of those listed above; the communication could take place
 over a LAN or an SDLC link.
 LAN workstations attached to the IBM PC Network (Baseband and Broadband) or
 IBM Token-Ring Network can communicate with each other, with an AS/400,
 System/36 (5363) or System/370 directly attached to the LAN.  If the LAN is
 remote to the host system, or is attached to the LAN using a gateway to
 communicate, the APPC transaction program must reside in the gateway, or a
 relay program must be written to run in the gateway.
 This relay program is needed because APPC/PC does not have the ability to
 examine an incoming connection request and re-route it to another APPC
 application (see Figure 73 under heading "5.6.1.3.1  APPC/PC").
 +------------------------------------------------------------------------------
 ]
 ]
 ]                   *---*
 ]                   ]   ]APPC/PC
 ]                   *---*
 ]                    :]
 ]   APPC/PC   *------:----------*                           System/370 host
 ]      *---*.........:    .........*---*                    *--------*
 ]      ]   ]--]           :     ]--]   ]------------        ]        ]
 ]      *---*  ]           :     ]  *---*.........../........] CICS   ]
 ]             *-----------:-----*  APPC            ---------]        ]
 ]                        ]:        relay                    ]        ]
 ]                      *---*       program                  *--------*
 ]                      ]   ]                                 CICS APPC
 ]                      *---*                                 application
 ]                      APPC
 ]                      transaction
 ]                      program
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 73. APPC/PC Connections
 Through its application programming interface, APPC/PC provides support for
 both mapped and basic conversations.
 Parallel sessions are supported when communicating with the following systems:
 o   AS/400
 o   System/36
 o   S/38
 o   Series/1
 o   Another APPC/PC.

 5.6.1.3.1.1  Software Requirements:  APPC/PC requires the IBM LAN Support
 Program V1.10 to provide the IEEE 802.2 LLC protocol and interface.

 5.6.1.3.2  OS/2 Extended Edition LU 6.2 Support:  APPC support of the OS/2 EE
 Communications Manager includes not only the base functions of the LU 6.2
 protocol, but also provides additional features.
 In this environment, a user does not have to issue control verbs like
 Attach_PU or Attach_LU, as is required when using APPC/PC under PC/DOS. The
 Application Subsystem shipped with Communications Manager uses the
 configuration file to perform the establishment of the SNA node and all the
 links with the other nodes. It also manages activation and deactivation of
 conversations by means of the automatic start of transaction programs (TPs).
 The major features of APPC support under OS/2 Extended Edition are:
 o   Connectivity via SDLC and IBM LAN adapters
 o   Acting as either a peer-to-peer (Type 2.1) or boundary function node (PU
     2.0)
 o   Link sharing with 3270 emulation LUs (LU 2.0)
 o   Support of multiple LUs
 o   Implicit partner LU support
 o   Support of parallel sessions
 o   Automatic session activation
 o   Remotely initiated TPs
 o   Multiple access by different TPs
 o   Use of locally known names (for example, LU aliases)
 o   Communication and System Management (C&SM) support
 o   Sending of alerts to the network resource specified in the configuration
     file
 o   Link congestion control
 o   Programming languages support:
     -   Macro Assembler
     -   Pascal
     -   C language.

 5.6.2  LAN Support Program Structure
 LAN Support Program modules are called DXMnnMOD.SYS where (nn =
 A0,C0,C1,T0,etc), which will be installed as device drivers (that is,
 extensions of the PC/DOS environment) under IBM PC/DOS 3.3 or 4.0.
 If two LAN adapters are installed in one LAN station, only one copy of each
 required device driver needs to be loaded.
 The A0 module, also called the interrupt arbitrator, is common for any IBM LAN
 adapter.  It provides the appropriate adapter support interface.
 The A0 module allows one optional parameter, the language for load-time error
 messages:
 o   01 - US English (default)
 o   44 - UK English
 o   33 - French
 o   49 - German
 o   39 - Italian
 o   34 - Spanish
 o   46 - Swedish.
 The LAN Support Program also contains:
 o   DXMAID.EXE: the LAN Support Program Installation Aid.
 o   DXMINFO.DOC: the LAN Support Program Online Documentation.
 o   TIMERINT.SYS: a device driver to replace obsolete ROM timer interrupt code
     on old PCs (a BIOSDATE.EXE is provided to determine the requirement for
     this driver).
 The installation aid will place the required device driver commands and
 default parameters in the CONFIG.SYS file according to the type of LAN adapter
 and the answers supplied while running the Installation Aid.

 5.6.2.1.1  IBM Token-Ring Network and LAN Support Program:  The IBM LAN
 Support Program V1.10 supports the new 16/4 Mbps IBM Token-Ring Network
 adapters.
 Support for the 64Kbytes of RAM, including implementation of RAM paging is
 provided.  RAM Paging enables use of the entire 64 Kbytes shared RAM on the
 adapter while only requiring 16 Kbytes in the PC memory.  This limits the risk
 of address range conflicts with other installed adapters, for example, a
 second LAN adapter.
 Both the data rate and the required shared RAM size are specified at adapter
 installation time via hardware switch settings on the Family 1 adapter, or a
 software adapter configuration file update for a Family 2 adapter.
 The structure of the IBM LAN Support Program V1.10 modules when supporting IBM
 Token-Ring Network adapters for token-ring attached workstations is shown in
 Figure 74 under heading "5.6.2.1.1  IBM Token-Ring Network and LAN Support
 Program":
 +------------------------------------------------------------------------------
 ]
 ]
 ]        * - - - >      *---*         *---*      <-- NetBIOS Interface
 ]        ]              ]T0 ]         ]T0 ]
 ]        ]              *---*         *---*
 ]      LAN          *-----------* *-----------*  <-- 802.2 LLC Interface
 ]  Support          ]    C0     ] ]    C1     ]
 ]  Program          *-----------* *-----------*
 ]        ]          *-------------------------*  <-- Direct Interface
 ]        ]          ]           A0            ]
 ]        * - - - >  *-------------------------*
 ]        * - - - >  *-------**-------**-------*
 ]        ]          ]  TRN  ]]  TRN  ]]16/4 TR]
 ] Adapters          ]Adapter]]Adapter]]Adapter]
 ]        ]          ]       ]]II , /A]]II , /A]
 ]        * - - - >  *-------**-------**-------*
 ]                   <--- Token Ring Network -->
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 74. LAN Support Program and IBM Token-Ring Network
 IBM LAN Support Program will provide the following device driver commands:
     DEVICE=\path\DXMA0MOD.SYS
     DEVICE=-path-DXMCnMOD.SYS
     local-addr-0,RAM-0,etr-0,local-addr-1,RAM-1,etr_1
     DEVICE=\path\DXMT0MOD.SYS p1=n1 p2=n2 ... / q1=m1 q2=m2 ...
 The C0 module supports IEEE 802.2 Class II operation and provides the
 appropriate interface.
 The C1 module supports IEEE 802.2 Class II operation and provides the
 appropriate interface for token-ring attached 3270-PCs and LAN stations
 running 3270 Workstation Program.
 When operating at 16 Mbps, use of the early token release option of the token
 passing ring MAC protocol is indicated by a parameter for the DXMCnMOD.SYS
 module in the CONFIG.SYS data set.
 Both Cn modules support positional parameters to specify operational values
 for the primary adapter (0) and an alternate adapter (1) if present:
 o   Local addr: locally administered address.
 o   RAM: mapping address for shared RAM (ignored for Family 2 Token-Ring
     adapters).
 o   ETR: early token release, 0 to use (default) or 1 to disable early token
     release (ignored if operating at 4 Mbps).
 The T0 module, which provides the common NetBIOS protocol and interface uses
 the LLC Interface provided by the Cn module through a specific NetBIOS service
 access point (SAP X'F0').
 The NetBIOS module parameters will not be discussed in detail in this
 document, as they are related to installation parameters of specific NetBIOS
 applications such as the IBM PC LAN Program and the IBM PC 3270 Emulation
 Program (Gateway and Network Station configurations). Refer to DXMINFO.DOC,
 the LAN Support Program Online Documentation file, and to the Raleigh ITSC
 publication INSTALLATION GUIDELINES FOR IBM TOKEN-RING NETWORK PRODUCTS.

 5.6.2.1.2  IBM PC Network (Broadband, Baseband) and LAN Support Program:  The
 structure of the IBM LAN Support Program V1.10 modules when supporting IBM PC
 Network (Broadband) or IBM PC Network Baseband is shown in Figure 75 under
 heading "5.6.2.1.2  IBM PC Network (Broadband, Baseband) and LAN Support
 Program".
 +------------------------------------------------------------------------------
 ]
 ]
 ]* - - - > *--**---*   *---*    *---*    *---*    *---*  <-- NetBIOS I/F
 ]]         ]  ]]T0 ]   ]T0 ]    ]T0 ]    ]T0 ]    ]T0 ]
 ]]         ]  ]*---*   *---*    *---*    *---*    *---*
 ]LAN       ]  ]*---**-------**-------**-------**-------* <-- 802.2 I/F
 ]Support   ]  ]]G2 ]]  G1   ]]  G0   ]]  G1   ]]  G0   ]
 ]Program   ]  ]*---**-------**-------**-------**-------*
 ]]         ]  ]*---------------------**----------------* <-- Direct I/F
 ]]         ]  ]]         A0          ]]       A0       ]
 ]* - - - > ]  ]*---------------------**----------------*
 ]* - - - > ]  *----**-------**-------**-------**-------*
 ]          ]PC Net ]]PC Net ]]PC Net ]]PC Net ]]PC Net ]
 ]Adapters  ](orig.)]]II Freq]]II/A Fr]]Baseb. ]]Baseb. ]
 ]          ]       ]]1, 2, 3]]1, 2, 3]]       ]]  /A   ]
 ]* - - - > *-------**-------**-------**-------**-------*
 ]          <-----PCNet Broadband-----><-PCNet Baseband->
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 75. LAN Support Program and IBM PC Network
 IBM LAN Support Program will provide the following device driver commands:
     DEVICE=\path\DXMA0MOD.SYS
     DEVICE=-path-DXMGnMOD.SYS local-addr-0,wrk-0,local-addr-1,wrk-1
     DEVICE=\path\DXMT0MOD.SYS p1=n1 p2=n2 ... / q1=m1 q2=m2 ...
 The Gn modules (n = 0, 1, 2; 31, 34, 38 Kbytes resp.) provide the same IEEE
 802.2 LLC interface on PC Network adapters as the Cn modules provide on
 token-ring adapters.  The G1 module is required to run Workstation Program on
 a LAN Station (or to operate the obsolete 3270-PC on a PC Network).  The G2
 module will bypass the ROM NetBIOS on an original PC Network Adapter.
 The Gn PC Network Device Drivers allow a maximum internal work area of 64
 Kbytes per adapter.  The amount of work space actually required depends on the
 requirements of the application program with respect to the number of
 concurrent NetBIOS sessions.  The default work space is 8 Kbytes for each PC
 Network Adapter and is valid for up to fifteen sessions.  Between fifteen and
 twenty-three sessions, a work space of 12 Kbytes is needed, while 16 Kbytes
 will be used if twenty-four to thirty-two sessions are used concurrently.  The
 WRK parameter of DXMGnMOD.SYS defines the desired internal work area size (in
 Kbytes).
 A common NetBIOS Interface device driver T0 (24 Kbytes), is accessed by the
 LLC Interface of the Gn module through a specific NetBIOS service access point
 (SAP X'F0').

 5.6.2.1.3  PC Network (Broadband) Coexistence:  Since the NetBIOS support
 residing in ROM on the original PC Network (Broadband) adapters is
 incompatible with the NetBIOS support required for the later PC Network
 (Broadband) II and II/A adapters, (module DXMT0MOD.SYS), two alternatives
 exist to address requirements for the devices to interoperate on a PC Network
 (Broadband).
 The DXMG2MOD.SYS module of the IBM LAN Support Program V1.10 bypasses the ROM
 NetBIOS on the original PC Network (Broadband) adapter.  It enables these
 adapters to use the IEEE 802.2 LLC interface to access other higher-level
 protocols such as APPC or the enhanced NetBIOS provided by the IBM LAN Support
 Program V1.10 This alternative requires processor memory for the additional
 LAN Support Program device drivers.
 The PC NETWORK PROTOCOL DRIVER program on a PC Network (Broadband) Adapter II
 or II/A provides a NetBIOS level which is compatible with the ROM NetBIOS on
 an original PC Network Adapter.
 This solution does not provide an open LLC interface and degrades the NetBIOS
 performance possible with the IBM LAN Support Program V1.10  Therefore it
 should only be considered if there are severe memory limitations on the PCs
 containing the original PC Network Adapters which would prevent them from
 using the IBM LAN Support Program V1.10.

 5.6.2.1.4  IBM LAN Support Program Structure -Summary:  Whenever a workstation
 contains two LAN adapters, only one copy of each common LAN Support Program
 module is required.
 IBM LAN Support Program requires DOS 3.3 or 4.0.  Figure 76 under heading
 "5.6.2.1.4  IBM LAN Support Program Structure -Summary" shows how the LU 6.2
 interface is made available through the IBM LAN Support Program V1.10 combined
 with the APPC/PC program.
 +------------------------------------------------------------------------------
 ]
 ]
 ]- - LU 6.2 - - - LU6.2 - - ]  ] - - LU 6.2 - - - LU 6.2 - - - LU 6.2 - -
 ]*-------------------------**--**---------------------**----------------*
 ]]         APPC/PC         ]]  ]]       APPC/PC       ]]     APPC/PC    ]
 ]*-------------------------*]  ]*---------------------**----------------*
 ]                           ]  ]
 ]- 802.2 LLC - - 802.2 LLC -]  ]- 802.2 LLC - - 802.2 LLC - - 802.2 LLC -
 ]*-----------* *-----------*]  ]*---**-------**-------**-------**-------*
 ]]    C1     ] ]    C0     ]]  ]]G2 ]]  G1   ]]  G0   ]]  G1   ]]  G0   ]
 ]*-----------* *-----------*]  ]*---**-------**-------**-------**-------*
 ]*-------------------------*]  ]*---------------------**----------------*
 ]]           A0            ]]  ]]         A0          ]]       A0       ]
 ]*-------------------------*]  ]*---------------------**----------------*
 ]                           ]  ]
 ]*-------**-------**-------*]  *----**-------**-------**-------**-------*
 ]]T-R Net]]T-R Net]]16/4 TR]]PC Net ]]PC Net ]]PC Net ]]PC Net ]]PC Net ]
 ]]Adapter]]Adapter]]Adapter]](orig.)]]II Freq]]II/A Fr]]Baseb. ]]Baseb. ]
 ]]       ]]II , /A]]II , /A]]       ]]1, 2, 3]]1, 2, 3]]       ]]  /A   ]
 ]*-------**-------**-------**-------**-------**-------**-------**-------*
 ]<-------Token-Ring--------><-----PCNet Broadband-----><-PCNet Baseband->
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 76. LAN Support Program and APPC/PC
 APPC/PC based applications may be run on any IBM LAN.  LU 6.2 support is
 accessed by the appropriate IBM LAN Support Program V1.10 LLC module through
 an SNA service access point (X'04', X'08', ...).
 APPC/PC is a separate product and can be also be run over an SDLC link.

 5.6.3  OS/2 Extended Edition 1.1 LAN Support Structure
 Figure 77 under heading "5.6.3  OS/2 Extended Edition 1.1 LAN Support
 Structure" shows the Communications Manager interfaces, including those for PC
 Network (Broadband), PC Network Baseband and the IBM Token-Ring Network.
 These LAN interfaces are very similar to the interfaces provided by IBM LAN
 Support Program V1.10.  Most of the commands are identical and the structure
 of the commands is very similar.
 As mentioned before, specific command control blocks (CCBs) are used to pass
 commands to the adapter support for OS/2 Extended Edition Communications
 Manager LAN support.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]             *----------------------------------------*                     ]
 ]             ]                                        ]                     ]
 ]             ]   Network Application Programs         ]                     ]
 ]             ]                 *-------------*        ]                     ]
 ]             ]                 ]  APPC  ]SRPI]        ]                     ]
 ]       *-----]                 ](LU 6.2)]----------*  ]                     ]
 ]       ]3101 ]                 ]        ]3270 Emul.]  ]                     ]
 ]       ]VT100]     *-----------+----------------------]                     ]
 ]       ]Emul.]     ]  NetBIOS  ]    Common Service    ]                     ]
 ]       ]-----------------------]    (Service Verbs)   ]                     ]
 ]       ]  ACDI  ]  IEEE 802.2  ]                      ]                     ]
 ]       ]----------------------------------------------]                     ]
 ]       ]          Operating System/2 Kernel           ]                     ]
 ]       ]----------------------------------------------]                     ]
 ]       ] Async ] PC Net ] Token-Ring ]  SDLC  ]  DFT  ]                     ]
 ]       *----------------------------------------------*                     ]
 ]          ] ]     ] ]        ] ]        ] ]      ] ]                        ]
 ]       *----------------------------------------------*                     ]
 ]       ]         Communications Adapter's I/O         ]                     ]
 ]       *----------------------------------------------*                     ]
 ]                                                                            ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 77. OS/2 Extended Edition 1.1 - Communications Manager Interfaces
 One operational consideration is that, whereas in the PC/DOS environment the
 adapter support and programming interfaces are separate product(s) which must
 be loaded after loading the operating system, in OS/2 Extended Edition 1.1 the
 adapter support program is an integral part of the operating system.
 As in the IBM LAN Support Program V1.10, the NetBIOS implementation in the
 Communications Manager of Operating System/2 Extended Edition V1.1 (trademark
 of the International Business Machines Corporation) runs on top of the IEEE
 802.2 interface.  It is used primarily to communicate between PC LAN Program
 requesters and servers or between Operating System/2 Extended Edition V1.1
 requesters and the OS/2 LAN Server. It is also available to network-specific
 applications.
 The NetBIOS commands provided by the Communications Manager of Operating
 System/2 Extended Edition V1.1 are identical to the ones described earlier for
 IBM LAN Support Program V1.10 (see "5.6.1.2 NetBIOS Interface").
 In an Operating System/2 Extended Edition V1.1 environment, IBM local area
 networks may be accessed indirectly through OS/2 dynamic link routines or
 directly via device driver calls. Two sublayer interfaces are available, IEEE
 802.2 logical link control and IEEE 802.5 medium access control (on IBM
 Token-Ring Network only).
 The 802.2 LLC interface supports both connectionless and connection-oriented
 services.  A multi-thread programming interface provides support for multiple
 application users.   It handles control blocks passed from NetBIOS, from APPC
 and from user applications concurrently.

 5.6.3.1.1.1  LAN support installation and configuration:  Operating System/2
 Extended Edition V1.1 uses configuration panels to define installation
 parameters for workstations attached IBM Token-Ring Network adapters and PC
 Network adapters.  These panels are presented to the user depending upon the
 workstation configuration data.
 Figure 78 under heading "5.6.3.1.1.1  LAN support installation and
 configuration" illustrates the profile panels for a token-ring adapter and
 Figure 79 under heading "5.6.3.1.1.1  LAN support installation and
 configuration" shows the profile panels for a PC Network adapter.
 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]*----------------------------------------------------------------------*    ]
 ]]           LAN IEEE 802.2 Profile for Token-Ring (1 of 2)             ]    ]
 ]]                                                                      ]    ]
 ]] Adapter number and version . . . . . :  n - /A                       ]    ]
 ]]                                                                      ]    ]
 ]] Adapter shared memory  . . . . . . . :                               ]    ]
 ]] Use Universally administered address :  Yes                          ]    ]
 ]] Adapter address  . . . . . . . . . . :                               ]    ]
 ]] Functional address . . . . . . . . . :                               ]    ]
 ]] Group address  . . . . . . . . . . . :                               ]    ]
 ]]                                                                      ]    ]
 ]] Maximum number SAPs  . . . . . . . . :  2                            ]    ]
 ]] Maximum link stations  . . . . . . . :  8                            ]    ]
 ]] Maximum number group SAPs  . . . . . :  0                            ]    ]
 ]] Maximum members per group SAP  . . . :  0                            ]    ]
 ]] Maximum number of users  . . . . . . :  2                            ]    ]
 ]]                                                                      ]    ]
 ]] Transmit buffer size . . . . . . . . :  1048   bytes                 ]    ]
 ]] Number of transmit buffers . . . . . :  2                            ]    ]
 ]] Receive buffer size  . . . . . . . . :  280    bytes                 ]    ]
 ]] Minimum receive buffers  . . . . . . :  10                           ]    ]
 ]]                                                                      ]    ]
 ]] System key (hex character) . . . . . :                               ]    ]
 ]]                                                                      ]    ]
 ]]----------------------------------------------------------------------]    ]
 ]] Esc=Cancel  F1=Help  F8=Forward                                      ]    ]
 ]*----------------------------------------------------------------------*    ]
 ]*----------------------------------------------------------------------*    ]
 ]]   Pass attention MAC frames default  . . . :  No                     ]    ]
 ]]   Monitor contention default . . . . . . . :  No                     ]    ]
 ]]   Pass beacon frames default . . . . . . . :  No                     ]    ]
 ]]                                                                      ]    ]
 ]] Group 1 Response Timer . . . . . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 1 Acknowledgement Timer  . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 1 Inactivity Timer . . . . . . . . . :  255 x  40 ms.          ]    ]
 ]] Group 2 Response Timer . . . . . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 2 Acknowledgement Timer  . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 2 Inactivity Timer . . . . . . . . . :  255 x  40 ms.          ]    ]
 ]]                                                                      ]    ]
 ]] Common LAN adapters queue size . . . . . . :  400 elements           ]    ]
 ]] Number Global Descriptor Table Selectors . :  50                     ]    ]
 ]] Attended mode of initialization  . . . . . :  No                     ]    ]
 ]]                                                                      ]    ]
 ]]----------------------------------------------------------------------]    ]
 ]] Esc=Cancel  F1=Help  F7=Backward                                     ]    ]
 ]*----------------------------------------------------------------------*    ]
 +----------------------------------------------------------------------------+
 Figure 78. OS/2 EE 1.1 - IEEE 802.2 Profile for Token-Ring

 +----------------------------------------------------------------------------+
 ]                                                                            ]
 ]                                                                            ]
 ]*----------------------------------------------------------------------*    ]
 ]]           LAN IEEE 802.2 Profile for PC Networks (1 of 2)            ]    ]
 ]]                                                                      ]    ]
 ]] Adapter number . . . . . . . . . . . :  n                            ]    ]
 ]]                                                                      ]    ]
 ]] Use Universally administered address :  Yes                          ]    ]
 ]] Adapter address  . . . . . . . . . . :                               ]    ]
 ]] Functional address . . . . . . . . . :                               ]    ]
 ]] Group address  . . . . . . . . . . . :                               ]    ]
 ]]                                                                      ]    ]
 ]] Maximum number SAPs  . . . . . . . . :  2                            ]    ]
 ]] Maximum link stations  . . . . . . . :  8                            ]    ]
 ]] Maximum number group SAPs  . . . . . :  0                            ]    ]
 ]] Maximum members per group SAP  . . . :  0                            ]    ]
 ]] Maximum number of users  . . . . . . :  2                            ]    ]
 ]]                                                                      ]    ]
 ]] Transmit buffer size . . . . . . . . :  1048   bytes                 ]    ]
 ]] Number of transmit buffers . . . . . :  2                            ]    ]
 ]] Receive buffer size  . . . . . . . . :  280    bytes                 ]    ]
 ]] Minimum receive buffers  . . . . . . :  10                           ]    ]
 ]]                                                                      ]    ]
 ]] Adapter workarea size  . . . . . . . :  16K                          ]    ]
 ]]                                                                      ]    ]
 ]]----------------------------------------------------------------------]    ]
 ]] Esc=Cancel  F1=Help  F8=Forward                                      ]    ]
 ]*----------------------------------------------------------------------*    ]
 ]                                                                            ]
 ]                                                                            ]
 ]*----------------------------------------------------------------------*    ]
 ]]           LAN IEEE 802.2 Profile for PC Networks (2 of 2)            ]    ]
 ]]                                                                      ]    ]
 ]] Adapter number . . . . . . . . . . . . . . :  n                      ]    ]
 ]]                                                                      ]    ]
 ]] Group 1 Response Timer . . . . . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 1 Acknowledgement Timer  . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 1 Inactivity Timer . . . . . . . . . :  255 x  40 ms.          ]    ]
 ]] Group 2 Response Timer . . . . . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 2 Acknowledgement Timer  . . . . . . :  50  x  40 ms.          ]    ]
 ]] Group 2 Inactivity Timer . . . . . . . . . :  255 x  40 ms.          ]    ]
 ]]                                                                      ]    ]
 ]] Common LAN adapters queue size . . . . . . :  400 elements           ]    ]
 ]] Number Global Descriptor Table Selectors . :  50                     ]    ]
 ]] Attended mode of initialization  . . . . . :  No                     ]    ]
 ]]                                                                      ]    ]
 ]]----------------------------------------------------------------------]    ]
 ]] Esc=Cancel  F1=Help  F7=Backward                                     ]    ]
 ]*----------------------------------------------------------------------*    ]
 ]                                                                            ]
 ]                                                                            ]
 +----------------------------------------------------------------------------+
 Figure 79. OS/2 EE 1.1 - IEEE 802.2 Profile for PC Networks
 Relevant parameters not described earlier are explained below:
 ADAPTER NUMBER AND VERSION
           An integer indicating whether the adapter is primary (0) or
           secondary (1) and the adapter type.
 ADAPTER SHARED MEMORY
           The shared RAM location in the workstation's memory.
 GROUP ADDRESS
           The group address is not used by the LAN data link control.  It
           needs only to be changed for other applications requiring a group
           SAP address.
 MAXIMUM NUMBER SAPS
           LAN data link control requires one dedicated service access point
           per adapter.  Additional application using SAPs must be considered
           in addition to this SAP.
 MAXIMUM LINK STATIONS
           The total number of link stations required by all LAN applications
           concurrently using the LAN adapter. Some applications may share SAP
           and link stations.
 MAXIMUM NUMBER GROUP SAPS
           Group SAPs are not used by LAN data link control.  This number needs
           to be changed only for other applications requiring a group SAP
           address.
 MAXIMUM MEMBERS PER GROUP SAP
           Group SAPs are not used by LAN data link control.  This number needs
           to be changed only for other applications requiring a Group SAP
           address.
 MAXIMUM NUMBER OF USERS
           LAN data link control is considered as one user of each active
           adapter. Other users/applications need to be added.
 TRANSMIT BUFFER SIZE
           This value must indicate the largest transmit buffer size used by
           any application using the LAN adapter.
 NUMBER OF TRANSMIT BUFFERS
           Due to limited shared RAM memory and the size of an SNA RU or
           non-SNA messages, one or two is considered optimal. There should be
           several receive buffers for each transmit buffer. There is some
           performance advantage in overlapped processing and I/O on the
           adapter for which two transmit buffers are required.
 RECEIVE BUFFER SIZE
           Ideally this value should be large enough to contain the average
           size data frame received on the network. The default value may have
           to be increased, depending on LAN application and data traffic
           characteristics.
 MINIMUM RECEIVE BUFFERS
           A minimum of two receive buffers is required to open the adapter.
           The remaining shared RAM memory, after all other storage
           requirements have been met, will be used for receive buffers.
 SYSTEM KEY (HEX CHARACTER)
           Specification of a key permits protection of adapter resources (for
           example, protection from conflict with other adapters)
 RESPONSE TIMER
           This timer is maintained by the sending adapter whenever an I-format
           LPDU frame is sent with the "Final" bit set (see "3.2.2.3 LLC
           Protocol Data Unit"). If this timer expires before a response is
           received, the sending stations solicits remote link station status.
           Therefore this value should be set greater than the total maximum
           frame delays within the sending station, the network and the
           destination station.
 ACKNOWLEDGEMENT TIMER
           This timer is started by a link station whenever an I-format LPDU
           frame is received into workstation memory, and stopped when an
           acknowledgement is sent either with an outgoing frame or when the
           number of I-format LPDUs received before sending acknowledgement
           (window size) is reached. If the timer expires, the link station
           should send an acknowledgement as soon as possible. The timer value
           should be shorter than the response timer to ensure that the remote
           link can receive the delayed acknowledgement before the response
           timer expires.
 INACTIVITY TIMER
           This timer runs whenever the response timer is not running.
           Expiration of this timer suggests that the link station may be lost.
           It should be set five to ten times greater than the response timer.
 ADAPTER WORKAREA SIZE
           The PC Network work area is used to maintain SAPs and link stations.
           The default value is 16 Kbytes.

 5.6.4  OS/2 EE 1.1 LAN Support versus IBM LAN Support Program V1.10
 Figure 80 under heading "5.6.4  OS/2 EE 1.1 LAN Support versus IBM LAN Support
 Program V1.10" compares IEEE 802.2 command support provided by Operating
 System/2 Extended Edition V1.1 Communications Manager with the IBM LAN Support
 Program V1.10 under IBM PC/DOS 3.3 or 4.0.
 In Operating System/2 Extended Edition V1.1 the Command Control Block (CCB) is
 changed by increasing the number of fields from 7 to 13 with a corresponding
 increase in CCB size from 16 to 26 bytes.  However, compatible offsets have
 been maintained for existing fields.
 The invocation of IEEE 802.2 services has changed as well.  Instead of
 Interrupt 5C, CALL LANCMDS (call to a dynamic link routine) is used.  Data
 structures should be aligned on even byte boundaries to avoid migration
 problems.

 *--------------------------------------------------------------------*
 ]   Commands                   ]    LAN Support   ]Operating System/2]
 ]                              ]      Program     ] Extended Edition ]
 ]------------------------------+------------------+------------------]
 ]                              ]                  ]                  ]
 ]Common Commands               ]                  ]                  ]
 ]   BUFFER.FREE                ]         X        ]         X        ]
 ]   BUFFER.GET                 ]         X        ]         X        ]
 ]   READ                       ]                  ]         X        ]
 ]   READ.CANCEL                ]                  ]         X        ]
 ]   RECEIVE                    ]         X        ]         X        ]
 ]   RECEIVE.CANCEL             ]         X        ]         X        ]
 ]   RECEIVE.MODIFY             ]         X        ]         X        ]
 ]   TRANSMIT                   ]         X        ]         X        ]
 ]                              ]                  ]                  ]
 ]DIRECT Interface Commands     ]                  ]                  ]
 ]   DIR.CLOSE.ADAPTER          ]         X        ]         X        ]
 ]   DIR.CLOSE.DIRECT           ]                  ]         X        ]
 ]   DIR.DEFINE.MIF.ENVIRONMENT ]         X        ]                  ]
 ]   DIR.IMPL.ENABLE            ]         X        ]                  ]
 ]   DIR.INITIALIZE             ]         X        ]         X        ]
 ]   DIR.INTERRUPT              ]         X        ]         X        ]
 ]   DIR.MODIFY.OPEN.PARM       ]         X        ]                  ]
 ]   DIR.OPEN.ADAPTER           ]         X        ]         X        ]
 ]   DIR.OPEN.DIRECT            ]                  ]         X        ]
 ]   DIR.READ.LOG               ]         X        ]         X        ]
 ]   DIR.RSTORE.OPEN.PARM       ]         X        ]                  ]
 ]   DIR.SET.EXCEPTION.FLAG     ]                  ]         X        ]
 ]   DIR.SET.FUNCTIONAL.ADDRESS ]         X        ]         X        ]
 ]   DIR.SET.GROUP.ADDRESS      ]         X        ]         X        ]
 ]   DIR.SET.USER.APPENDAGE     ]         X        ]                  ]
 ]   DIR.STATUS                 ]         X        ]         X        ]
 ]   DIR.TIMER.CANCEL           ]         X        ]         X        ]
 ]   DIR.TIMER.CANCEL.GROUP     ]         X        ]         X        ]
 ]   DIR.TIMER.SET              ]         X        ]         X        ]
 ]                              ]                  ]                  ]
 ]DLC Commands                  ]                  ]                  ]
 ]   DLC.CLOSE.SAP              ]         X        ]         X        ]
 ]   DLC.CLOSE.STATION          ]         X        ]         X        ]
 ]   DLC.CONNECT.STATION        ]         X        ]         X        ]
 ]   DLC.FLOW.CONTROL           ]         X        ]         X        ]
 ]   DLC.MODIFY                 ]         X        ]         X        ]
 ]   DLC.OPEN.SAP               ]         X        ]         X        ]
 ]   DLC.OPEN.STATION           ]         X        ]         X        ]
 ]   DLC.REALLOCATE.STATIONS    ]         X        ]         X        ]
 ]   DLC.RESET                  ]         X        ]         X        ]
 ]   DLC.SET.THRESHOLD          ]                  ]         X        ]
 ]   DLC.STATISTICS             ]         X        ]         X        ]
 *--------------------------------------------------------------------*

 Figure 80. OS/2 EE 1.1 and LAN Support Program 802.2 Commands

 5.6.5  IBM LAN Support Program Version 1.2
 The IBM LAN Support Program Version 1.2 includes all the function and
 capabilities of the earlier releases of LAN Support Program.  That is, it
 provides interface code between applications written to the IEEE 802.2, IEEE
 802.5 or NetBIOS interface, and token-ring and IBM PC Network attachment
 cards.
 In addition, version 1.2 extends support to include Ethernet DIX (Digital
 Intel Xerox) Version 2 and IEEE 802.3 local area networks.
 This means that IBM Personal Computers and Personal System/2 workstations
 running the DOS operating system and attached to Ethernet LAN segments can
 access stations such as SNA gateways or application processors attached to
 token-rings.  Connectivity to the token-ring networks would be via the IBM
 8209 LAN Bridge, see "6.7.2 Token-Ring to Ethernet/IEEE 802.3."
 The mechanism for providing this function is by support of the NETWORK DEVICE
 INTERFACE SPECIFICATION , (NDIS).

 5.6.5.1.1  Network Device Interface Specification:  NDIS is an evolving
 "industry standard" that was developed by 3Com and Microsoft as a means of
 ensuring that applications, particularly server applications, could interface
 to the wide range of Ethernet cards provided by different manufacturers.  It
 is a programming interface at the MAC layer, equivalent to the direct
 interface in IEEE 802.5.
 By using this "standard" programming interface, the characteristics of the
 card are isolated from the application program. Hence the application can be
 coded independently of the card installed.
 The version of NDIS supported by the IBM LAN Support Program Version 1.2 is
 known as NDIS 1.01.
 Similar support is announced for the OS/2 Operating System, with OS/2 Extended
 Edition Version 1.2.
 The application interface support offered by LAN Support Program 1.2 is
 summarized in Figure 81 under heading "5.6.5.1.1  Network Device Interface
 Specification".
 -------------------------------------------------------------------------------

      *------------------------------------------------------*
      ]                                                      ]
      ]                 User Application                     ]
      ]                                                      ]
      *------------------------------------------------------*
              ]                   ]                   ]
              ]                   ]                   V
              ]                   ]           *--------------*
              ]                   ]           ]              ]
              ]                   ]           ]    NetBIOS   ]
              ]                   ]           ]              ]
              ]                   ]           *--------------*
              ]                   ]                   ]
              ]                   V                   V
              ]     *----------------------------------------*
              ]     ]                                        ]
              ]     ]              IEEE 802.2                ]
              ]     ]                                        ]
              ]     *----------------------------------------*
              ]         ]         ]                   ]
              V         V         ]                   V
      *--------------------*      ]           *--------------*
      ]                    ]      ]           ]              ]
      ]    IEEE 802.5      ]      ]           ]   NDIS 1.01  ]
      ]                    ]      ]           ]              ]
      *--------------------*      ]           *--------------*
              ]                   ]                   ]
              V                   V                   V
      *--------------*    *--------------*    *--------------*
      ]  Token-Ring  ]    ]  PC Network  ]    ]   Ethernet   ]
      ]   Adapter    ]    ]    Adapter   ]    ]    Adapter   ]
      *--------------*    *--------------*    *--------------*

       IBM token-ring      IBM PC Network      Supported Ethernet
       adapters for        adapters for        adapters
       PC and PS/2         PC and PS/2

 -------------------------------------------------------------------------------
 Figure 81. LAN Support Program Version 1.2 - LAN Interface Support
 The LAN Support Program V1.2 supports up to two adapters per workstation.
 These adapters can be:
 o   Any IBM Token-Ring Network adapter
 o   Any of the existing IBM PC Network adapters
 o   A supported Ethernet adapter card for operating on the Ethernet DIX
     Version 2 or IEEE 802.3 network. These are the:
     -   3Com Etherlink II (Model 3C503)
     -   3Com Etherlink/MC (Model 3C5203)
     -   Western Digital Ethercard PLUS (Model WDLAN-ERP-F001)
     -   Western Digital Ethercard PLUS/A (Model WDLAN-EP/A-F001).
 The Ethernet cards require their NDIS device driver.  The driver is usually
 included on the diskette packaged with the card.
 o   MACWD.DOS is the driver for the Western Digital Ethercard PLUS and
     Ethercard PLUS/A.
 o   ELNKII.DOS is the driver for the 3Com Etherlink II and ELNKMC.DOS for the
     3Com Etherlink/MC.

 5.6.6  OS/2 Extended Edition 1.2 LAN Support
 OS/2 Extended Edition 1.2 introduced ETHERAND support, which enables IBM PCs
 and PS/2s to attach to Ethernet/IEEE 802.3 networks and be able to communicate
 with each other or host gateways using the IEEE 802.2 and NetBIOS protocols. A
 similar implementation in PC/DOS has already been discussed in "5.6.5 IBM LAN
 Support Program Version 1.2."

 5.7  3174-Peer Communications RPQ 8Q0718
 Many customers have a large installed base of 3270 equipment, screens and
 printers, that are attached to 3174 Establishment Control Units via coax
 cabling.  This equipment has been traditionally used for accessing IBM
 System/370 mainframes for interactive work; for example accessing databases or
 program development. Today, many end-users are seeing benefits in the use of
 programmable workstations for processing their data. At the same time, the
 need for mainframe access is maintained.
 Connecting a programmable workstation to a 3174 Establishment Control Unit has
 been possible for some time. A suitable 3270 emulator program, such as the IBM
 PC 3270 Emulator Entry Level, running in the workstation has provided the
 mainframe access, but with this approach the end-users were unable to gain the
 benefit of being attached to a LAN. They could not share data, applications,
 and gateway access between each other. The solution was to attach the
 workstations directly to the LAN. This meant that in many customer locations,
 an investment in recabling was required, since the coax cabling used between
 workstation and 3174 Controller was not suitable for token-ring use.
 Many miles of this 3270 coaxial cabling are installed in customers premises.
 To replace it involves considerable costs, and often major disruption to
 end-user services, both factors which may make the exercise prohibitive.
 Installing a structured cabling system, based on shielded twisted pair is a
 sensible approach in a new or re-furbished building; less easy in an existing
 coax-cabled location.
 The 3174-Peer Communications Request-for-Price-Quotation (RPQ) allows
 programmable workstations, connected by coaxial or unshielded twisted pair
 cabling to IBM 3174 Establishment Control Units, to obtain the benefits of
 being attached to a LAN, at the same time being able to access IBM hosts. If
 the 3174 is itself attached to a token-ring, the workstations can communicate
 with other stations on the token-ring.  The RPQ is therefore able to act as a
 migration aid for customers who for cost or cabling considerations are not
 able to implement a full token-ring installation.

 5.7.1  General description
 The 3174-Peer Communication RPQ allows a LAN environment (3174-LAN) to be
 established for workstations attached to 3270 wiring.  Workstations use their
 existing 3270 attachment cards, protecting customer investment. The RPQ, in
 conjunction with the 3174 Workstation Peer Communication Support Program
 (3174-WPCSP), provides full IEEE 802.2 support for the workstations, allowing
 them to run applications written to the IEEE 802.2 or NetBIOS interfaces
 peer-to-peer. These may include 3270 Emulators, APPC/PC or LAN
 server/requester programs.
 The 3174 is required to have a 3174 Type 3A Dual-Speed Adapter installed, and
 the RPQ allows this adapter to act as a bridge between the 3174-LAN segment
 and any establishment token-ring. Thus the stations on the 3174-LAN segment
 can transparently access any other station as though they were attached
 directly to the ring. This is shown in Figure 82 under heading "5.7.1  General
 description".
 -------------------------------------------------------------------------------

                      *---------*  *---------*
                      ]  Host   ]  ] Appl.   ]
                      ] Gateway ]  ] Process.]
                      *---------*  *---------*
                           ]            ]
                    *--------------------------*
 *-------------*    ]                          ]   *--------------*
 ] File Server ]----] Establishment Token-Ring ]---] Print Server ]
 *-------------*    ]                          ]   *--------------*
                    *--------------------------*
                                 ]
                                 ]
                       *---------+----------*
                       ] *----------------* ]
                       ] ]3174-Peer Bridge] ]
                       ] ]    function    ] ]
            3174 x3R   ] *----------------* ]
              with     ]         ]          ]
           3174-Peer   ]  *------------*    ]
         Communication ]  ]    3174    ]    ]
              RPQ      ]  ]" Peer LAN "]    ]
                       ]  ]  function  ]    ]
                       ]  *------------*    ]
                       ]     ]      ]       ]
                       *-----+------+-------*
                             ]      ]
                      Coax Port     Coax Port
                         #1           #32
                             ]      ]
                             ]      ]
   *---------*               ]      ]               *---------*
   ] PS/2 ]  ]               ]      ]               ]  ]  PC  ]
   ]   A  ]  ]---------------*      *---------------]  ]  B   ]
   *---------*                                      *---------*
            A       IBM 3174  Workstation  Peer      A
            *-----Communication Support  Program-----*
                           (5799-PHL)

                 IBM 3270 Connection card (Family 2)
             IBM 3278/9 Emulation Adapter Card (Family 1)
 -------------------------------------------------------------------------------
 Figure 82. 3174-Peer Communication RPQ
 With reference to the figure, "PS/2 A" is able to access "PC B" using LAN
 applications, as well as the file server, print server, communications gateway
 and application processor on the establishment token-ring. "PC B" has the same
 capability.
 Fixed function 3270 terminals (3278,3279,3192 etc.) attached to the 3174 are
 handled in the usual way by the 3174 microcode. The RPQ only provides LAN
 function to those workstations that have the 3174 Workstation Peer
 Communication Support Program installed.

 5.7.1.1.1  3270 Host Access:  A variety of options are available, depending on
 software, 3174 model, and whether or not the 3174 is attached to a real
 token-ring.  The 3174 is able to support the workstations as either 3174-LAN
 devices or 3270 control unit terminal (CUT) / distributed function terminal
 (DFT) devices. The 3174 recognizes which method is being used by analyzing the
 protocol used on the coax when the station loads its software and connects to
 the 3174.
 If the 3174 Workstation Peer Communication Support Program is loaded as a
 device driver in the workstation, the 3174 places the workstation on the
 3174-LAN segment. If the workstation powers on and does not include the
 3174-WPCSP as a device driver in its configuration, it may load a DFT or CUT
 mode emulator and work as such a device.  Therefore, a given workstation can
 flip between 3174-LAN mode and CUT/DFT mode, depending on the software loaded.
 It CANNOT use LAN and CUT/DFT concurrently.
 If the workstation is considered to be on the 3174-LAN segment, then the
 workstation software used for host access can be IBM Personal
 Communications/3270 or IBM Workstation Program, configured as a SNA physical
 unit (PU) together with logical units (LUs).  Personal Communications/3270 may
 also be used as a 3270 DFT emulator.
 When workstations are attached to the 3174-LAN segment, they access the S/370
 host as would a token-ring attached station. That is, they use an SNA host
 gateway, such as the IBM 3745 or IBM 3174 Model 01L.  If the 3174 to which
 they are attached has the token-ring gateway feature installed, they can use
 that 3174 as their gateway. Some possible configurations are shown in
 Figure 83 under heading "5.7.1.1.1  3270 Host Access"
 -------------------------------------------------------------------------------

        *------*                            *------*
        ] Host ]                            ] Host ]
        *------*                            *------*
            ]                                   ]
        *------*IBM 3174-01L                *------*
        ]      ]or IBM 3745                 ]      ]IBM 3745
        *------*Gateway                     *------*
            ]                                   ]
      *----------*                              ]/]Telecommunications
      ]token-ring]                                ]link
      *----------*                                ]
            ]                                     ]
       *--------*                            *--------*
       ]        ]IBM 3174-03R                ]        ]IBM 3174-01R
       ]*------*]3174-Peer RPQ               ]*------*]Token-ring gateway
       ]*------*]                            ]*------*]3174-Peer RPQ
       *-+----+-*                            *-+----+-*
         ]    ]                                ]    ]
        *-*  *-*PC/3270 V1                    *-*  *-*PC/3270 V1
        *-*  *-*3174-WPCSP                    *-*  *-*3174-WPCSP

 1) The 3174 is attached to              2) The 3174 is link attached.
    a real token-ring.                      It must have the token-ring
    The workstations are                    gateway feature present.
    seen as DSPUs of the                    The workstations are PUs
    3745 or 3174 gateway.                   on a "multipoint" line.

        *------*
        ] Host ]
        *------*
            ]                               *-------*
        *------*                            ] Host  ]
        ]      ]IBM 3745                    *-------*
        *------*                               ]]
            ]                                  ]]
            ]/]Telecommunications          *--------*
              ]link                        ]        ]IBM 3174-01L
              ]                            ]*------*]Token-ring gateway
 token-       ]                            ]*------*]3174-Peer RPQ
 ring    *--------*                        *-+----+-*
 *-----* ]        ]IBM 3174-12R              ]    ]
 ]     ]-]*------*]Token-ring gateway       *-*  *-*PC/3270 V1
 *-----* ]*------*]3174-Peer RPQ            *-*  *-*3174-WPCSP
   *-*   *-+----+-*
   *-*     ]    ]
          *-*  *-*PC/3270 V1             4) The 3174 is channel attached
          *-*  *-*3174-WPCSP                to the S/370 host.
                                            No local token-ring exists.
 3) The 3174 is link attached and
    acting as a gateway for stations
    on the token-ring.

 -------------------------------------------------------------------------------
 Figure 83. Typical 3174-Peer Communications Host Connectivity
 Scenarios 2 and 4 of Figure 83 under heading "5.7.1.1.1  3270 Host Access"
 require that the 3174-Peer Communications machines have a Type 3A Dual-Speed
 adapter installed  even though there is no token-ring present. This adapter is
 the only adapter supported by the 3174-Peer Communications RPQ and must always
 be installed, even if there is no real token-ring present. It provides the
 token-ring logical link control function within the 3174. If the 3174 is not
 attaching to a real token-ring, the card does not have to be plugged into a
 token-ring access unit; it works in a wrap mode using the cable provided with
 the card. A patch to the RPQ microcode is required when working in this way.

 5.7.2  Customization and Management
 Stations attached to the 3174-LAN segment have token-ring MAC addresses as
 would stations attached directly to a token-ring. The bridge function within
 the 3174 has a bridge number, and the 3174-LAN segment a ring number. The
 bridge provides full source routing support.  However, the bridge is not
 visible to the IBM LAN Manager or IBM LAN System Manager.
 During 3174-Peer customization, values are assigned to reflect the:
 o   Individual MAC addresses of the 3174-Peer devices
 o   Bridge number of the 3174-Peer bridge function within the controller
 o   Segment number of the 3174-LAN segment
 o   Hop count of the 3174-Peer bridge
 o   Initial forwarding status of the 3174-Peer bridge
 o   Performance thresholds.
 Management of the 3174-LAN segment is provided through the 3174 online test
 menus. A CUT mode device is required to manage the 3174 Peer LAN segment.
 The tests allow the operator to display status information and control
 attachment of the 3174-Peer devices. The status and configuration of the
 3174-Peer bridge, together with similar performance statistics to those
 viewable on IBM token-ring bridges can also be obtained via the menu driven
 interface.

 5.7.3  Hardware/Software Requirements
 The 3174-Peer Communication RPQ can be installed in 3174 models:
 o   01L, 21L, 01R, and 51R with features 3026, 3030, or 3044
 o   11L, 21R, 11R, and 61R with features 3026 or 3044
 o   03R and 53R with feature 3030
 o   13R and 63R
 o   02R, 12R and 62R with features 3026 or 3044.
 The RPQ is offered on a base of 3174 Configuration Support B Release 1.1 or
 Release 3.
 IBM 3174 Workstation Peer Communication Support Program (5799-PHL) is the
 corequisite software RPQ that must be installed in the coax-attached
 workstations. This program provides the same function as the IBM LAN Support
 Program in the workstation, interfacing to either the IBM 3278/9 Emulation
 Adapter Card or the IBM 3270 Connection Card.  The program provides the IEEE
 802.2 and NetBIOS application interfaces, together with the logical link
 control required for token-ring operation. Applications believe that they are
 working directly on the token-ring.
 On the PC or PS/2, software supporting the 3174-Peer Workstation Communication
 Support Program is:
 o   IBM Personal Communication/3270 V1.0
 o   IBM 3270 Workstation Program V1.12
 o   IBM Advanced Program-to-Program Communications (APPC/PC) V1.11
 o   IBM PC Local Area Network Program V1.32
 o   IBM DOS LAN Requester (included with OS/2 LAN Server V1.2)

 5.7.4  Summary
 The 3174-Peer Communications RPQ, in conjunction with the 3174 Workstation
 Peer Communication Support Program allows DOS based Personal Computers and
 Personal System/2 workstations attached by 3270 wiring to IBM 3174s to
 communicate with each other, with token-ring attached devices and System/370
 hosts as though they were attached directly to a token-ring.
 The RPQ provides a solution for those customers who are unable, for whatever
 reason, to implement a full token-ring LAN, yet wish to provide end users with
 LAN capability.
 The RPQ provides a cost effective way to migrate to a LAN environment using
 existing installed controllers, 3270 cabling and workstation adapters.
 The RPQ can be fitted to any model of the 3174 Establishment Control Unit
 family, except Models 8xR, 9xR and 52R, provided that enough storage and the
 requisite features are present.
 The RPQ requires 3174 licensed microcode level B1.1 or B3 or above to operate.

 5.8  IBM LAN Offerings Summary
 The IBM Token-Ring Network is IBM's strategic LAN offering for the campus and
 office environment.  It offers extensive, continuously evolving device
 attachment capability, including workstations, communications devices and
 mid-range systems.
 The 16 Mbps data rate capability, with announced support by large number of
 attaching devices, stresses the importance of the IBM Token-Ring Network as a
 viable backbone LAN in addition to high-speed LAN functions.  The topology,
 protocol, and performance characteristics that make the 16 Mbps Token-Ring
 Network desirable as a backbone LAN today, also offer the potential for
 ultimate coexistence and operation as cost-effective intermediate or
 supporting rings in future FDDI backbone LANs.
 Connectivity improvements to the IBM PC Network resulting from the ability to
 bridge to Token-Ring Networks and to attach workstations to multichannel
 networks using industry standard high-split channel distribution frequencies
 make PC Network (Broadband) solutions more attractive in environments
 requiring broadband multipurpose cable (such as concurrent video and data) and
 broadband manufacturing LANs for which MAP 3.0 support is not yet available or
 required.
 The IBM PC Network Baseband is a low-cost LAN, though with recent IBM
 announcements that include support for chaining of extender units as well as
 support by the IBM PC Network Bridge Program, workstation access to both other
 workstations on the same LAN and to token-ring connected devices is improved.
 Attached workstations use the LAN Support Program to obtain support equivalent
 to that provided to IBM Token-Ring Network and PC Network (Broadband)
 workstations.  This includes use of the IEEE 802.2 LLC interface and access to
 both NetBIOS and APPC/PC (LU 6.2).
 With the announcement of support for Ethernet and IEEE 802.3 attached PC and
 PS/2 workstations, using LAN Support Program 1.2 in the PC/DOS environment and
 OS/2 Extended Edition 1.2 and bridging possible between Ethernets,
 token-rings, and PC Networks, a logical single LAN can be created from
 segments with very different MAC protocols with huge connectivity potential.
 With software support for all the base programming interfaces possible on all
 adapter types, a consistent application base may be built.

 6.0 LAN Segments Interconnection

 6.1  Bridges, Routers and Gateways
 Interconnection of LAN segments may be supported by one or more of the
 following three approaches:
 o   A bridge
 o   A router
 o   A gateway.
 What are the fundamental differences between these approaches?  Perhaps the
 easiest way to show the difference is by reference to the OSI model for data
 communications as illustrated in Figure 84 under heading "6.1  Bridges,
 Routers and Gateways" below.
 -------------------------------------------------------------------------------

    *-------------------*                    *-------------------*
    ]                   ]          A         ]                   ]
    ] Application       ]          ]         ] Application       ]
    ]                   ]                    ]                   ]
    ]-------------------]          ]         ]-------------------]
    ]                   ]                    ]                   ]
    ] Presentation      ]          ]         ] Gateway           ]
    ]                   ]                    ]                   ]
    ]-------------------]          ]         ]-------------------]
    ]                   ]                    ]                   ]
    ] Session           ]   Gateway]         ] Session           ]
    ]                   ]                    ]                   ]
    ]-------------------]          ]         ]-------------------]
    ]                   ]                    ]                   ]
    ] Transport         ]          ]         ] Transport         ]
    ]                   ]                    ]                   ]
    ]-------------------]          A         ]-------------------]
    ]                   ]          ]         ]                   ]
    ] Network           ]          ]       A ] Network           ]
    ]                   ]          ]       ] ]                   ]
    ]-------------------]          ]       ] ]-------------------]
    ]                   ]          ]       ] ]                   ]
    ] Data Link Control ] A        ] Router] ] Data Link Control ]
    ]                   ] ]        ]       ] ]                   ]
    ]-------------------] ]Bridge  ]       ] ]-------------------]
    ]                   ] ]        ]       ] ]                   ]
    ] Physical          ] ]        ]       ] ] Physical          ]
    ]                   ] ]        ]       ] ]                   ]
    *-------------------* V        V       V *-------------------*
 -------------------------------------------------------------------------------
 Figure 84. OSI Model - Bridge/Router/Gateway
 A BRIDGE operates at layer 2 of the model. A bridge performs the function of a
 Medium Access Control (MAC) relay, and therefore may be independent of any
 higher layer protocol, (including the logical link protocol).  It can
 therefore be used to transport multiple higher layer protocols from one LAN to
 another. In the simplest case, their use is to extend a LAN quickly and
 easily, a step that may be needed for a variety of reasons. Some of these are
 listed below.
 One of the main advantages is that installing a bridge has little impact on
 end-user communications. However, application and logical link timers may have
 to be adjusted if a remote bridge is installed that uses a relatively slow
 communications link.
 A bridge only needs to do two things; to filter the frames arriving to decide
 whether they need to be forwarded over the bridge, and then to forward them to
 the other bridge port. This makes them relatively simple devices, hence fast
 and efficient.
 Bridges are available to interconnect LAN segments that have different Medium
 Access Control (MAC) protocols. As will be seen later on in this chapter, the
 IBM 8209 Token-Ring/Ethernet Bridge (see "6.7.2 Token-Ring to Ethernet/IEEE
 802.3") and the IBM PC Network Bridge (see "6.6.3 IBM PC Network Bridge
 Program") are able to do exactly that. But even when a MAC layer protocol
 conversion is required, transparency to higher layer protocols is maintained.
 If a connection-oriented protocol is being used, the logical link is
 end-to-end between the communicating stations.
 A ROUTER  generally provides functions equivalent to the Network layer (layer
 3).  This means that it will only support particular networking protocols, for
 instance TCP/IP, or NETBIOS.  Therefore, when a router is installed to
 interconnect segments, care must be taken to select a device that is able to
 route the required protocols.  Nowadays, routers are available that are able
 to interpret a wide range of standard and proprietary protocols. Some are
 capable of supporting multiple protocols within a single router station.
 Whereas bridges are able to use the FLAT ADDRESS SPACE provided by stations'
 MAC addresses, routers tend to rely on a hierarchical addressing structure so
 that they can make their routing decisions.  A good example of a hierarchical
 addressing structure is provided by the telephone numbering system. Dialling
 an international number from an office may mean entering many numbers, but
 their function is to route, based on a hierarchy of telephone switching
 exchanges.
 For instance - 9-011-44-71-123-4567
 9   PABX - Give me an outside line, route to a local telephone exchange
 011 Local exchange - route me to the international exchange
 44  International exchange - route me to the United Kingdom
 71  United Kingdom - route me to London, etc, etc.
 If we wanted to dial another city within the United Kingdom, then the London
 code would be the number to change; up to that point the routing required
 would be the same, and hence the number that would be dialled. The implication
 of this is that when a router is added to the network, the hierarchy of
 addressing must be understood, and the impact of a change in the addressing
 structure on the applications assessed.
 Thus routers must understand the addressing structure and take decisions on
 whether, or how, to forward frames. This structure may have to be defined to
 them, as in SNA subarea networking, or they might be able to learn it by means
 of some protocol flowing between the routers, as in SNA APPN.  The Internet
 protocol, as used in TCP/IP, uses a structure that divides addresses into a
 NETWORK ADDRESS and a HOST ADDRESS. The routers forward frames between the
 connected networking segments on the basis of the network address until the
 destination network is found.
 Routers are very often used to interconnect LAN segments that are
 geographically separated, and use wide area network services provided by the
 PTTs. This means that a more limited bandwidth is available than that provided
 within a local area network. To utilize this limited bandwidth effectively, it
 is desirable to stop BROADCAST frames being routed over the WAN. Although
 these frames may have little impact on LAN utilization, they can severely
 impact WAN performance and throughput.  Hence, routers will usually forward
 traffic that is explicitly addressed to them, blocking uncontrolled broadcast
 traffic.
 The protocol used between routers can be proprietary, that is it can be
 defined by the implementer. The choice may depend on what sort of wide area
 network the router is to use between the various routing devices.
 The GATEWAY is the final method of interconnecting LAN segments. A gateway is
 a system function that supports more than one communication architecture or
 network addressing scheme to permit connectivity and interoperability between
 the devices in the attached environments.
 Gateway products usually support address mapping from one network to another,
 and may also provide transformation of the data between the environments to
 support end-to-end application connectivity. Gateways usually link networks at
 higher layers than bridges or routers, ranging from layer 3 to layer 7.

 6.2  Bridged LANs
 A prime reason for considering bridging LANs is to expand the networking
 capability by:
 o   Increasing the geographic area covered by the total LAN
 o   Increasing the number of attached devices or wiring closets above that
     supported on a single LAN segment
 o   Providing connectivity between stations attached to different LAN segments
     so that segment differences (due to use of different MAC protocols, speeds
     or frequencies) are transparent to higher layer protocols
 o   Increasing the bandwidth available to stations on a single segment by
     splitting a LAN segment into one or more bridged LAN segments. In this way
     fewer stations have to share the same common medium and access protocol
     mechanisms.
 Even when LAN stations use the same MAC protocol, there may be other physical
 constraints preventing a station from joining a particular LAN segment. In the
 case of the IBM Token-Ring, bridge interconnection is required when:
 o   The maximum number of stations attached to a single physical ring for a
     given type of media has been reached (see "5.1.1.1 Cabling Components").
 o   Some stations are attached via unshielded telephone twisted pair wire
     while all others are attached to data grade media twisted pair wire. It is
     not an IBM recommendation that shielded and unshielded wiring be mixed
     within a single physical ring.
 For the IBM PC Network, bridging will be required when stations that require
 to communicate are attached to broadband segments that use different channel
 pairs to transmit and receive information (see "5.1.3 IBM PC Network
 (Broadband) Components"), or it is required to bridge a PC Network (Broadband
 or Baseband) segment to a token-ring or another PC Network segment.
 LAN bridging provides autonomous network management entities ("9.0 LAN
 Management and Recovery"), and may reduce installation and maintenance
 required in fast growing LAN environments.  Network availability may be
 further improved by providing alternate connectivity paths across bridges.

 6.2.1  Bridge Configurations
 Many factors should be considered when configuring a LAN consisting of a
 number of interconnected LAN segments, each with its own (perhaps different)
 MAC protocol.
 This section introduces different topology considerations for interconnected
 LAN segments.  Topologies associated with protocols for various single segment
 LAN (segment) were described in "2.1.2 Network Topologies."
 Bridged LAN topology can be influenced by any of the following:
 o   The number of workstations physically supported by a particular type of
     LAN or cabling.
 o   Requirements to balance or alleviate heavy traffic associated with
     particular applications over one or more interconnected LAN segments.
 o   Requirements for a geographical approach to interconnecting LAN segments
     by associating segments with specific areas within a building or campus
     layout.
 o   Desire to concentrate communications by connecting users with related
     information needs within LAN segments, known as affinity groups.
 o   Requirements for performance, reliability and/or availability which may be
     addressed through use of parallel bridges (16 under heading "6.2.1  Bridge
     Configurations") or parallel routes (17 under heading "6.2.1  Bridge
     Configurations"), providing both increased capacity and backup paths.

 ---Footnote---
 (16) Parallel bridges are bridges interconnecting the same two LAN segments.
 --------------

 ---Footnote---
 (17) Parallel routes define multiple end-to-end paths for the same source and
 destination LAN segments.
 --------------

 o   Requirements to separate some LAN stations from others for security
     purposes by using bridges to provide controllable connectivity paths
     between secure segments and other stations.
 o   Requirements to access special function devices such as host gateways or
     LAN servers which may be best satisfied through use of a backbone
     topology.
 It is evident that there is no "best solution" for every network.  However,
 general guidelines can be given based on the strengths and weaknesses of
 general topologies, and possible performance expectations.

 6.2.1.1.1  General Guidelines:  When the number of workstations is small
 (typically a network of fewer than 40 workstations) the distribution of
 workstations within the network will be determined mainly by physical
 considerations.  The existence of departmental groups or affinity groups will
 also be an important factor in selecting a particular physical layout, as will
 the number and location of servers.
 However, when the number of workstations grows, other factors (such as
 increased traffic load versus capacity, availability, performance, management
 and network expandability), increase in importance.
 In the remainder of this design section, we will primarily consider bridges
 interconnecting two token-ring LAN segments, although other segment topologies
 and MAC protocols could equally apply except where noted.
 o   SERVER LAN CONFIGURATION

     If two work groups or departments share similar files or printers, but are
     attached to separate rings for other reasons, a server ring can be used to
     reduce the costs of providing such resources as letter quality printers or
     large disk storage. See Figure 85 under heading "6.2.1.1.1  General
     Guidelines".

 -------------------------------------------------------------------------------

           *-----------*           *-----------*   *---*
           ]           ]           ]           ]---]   ]
           ]    LAN    ]   *---*   ]    LAN    ]   *---*   File and
           ]           ]---]   ]---]           ]           Printer
           ]     A     ]   *---*   ]     B     ]   *---*   Servers
           ]           ]   BRIDGE  ]           ]---]   ]
           *-----------*           *-----------*   *---*
                                         ]
                                       *---*
                                 BRIDGE]   ]
                                       *---*
                                         ]
                                   *-----------*
                                   ]           ]
                                   ]    LAN    ]
                                   ]           ]
                                   ]     C     ]
                                   ]           ]
                                   *-----------*

 -------------------------------------------------------------------------------
 Figure 85. Server LAN Configuration.  LAN A and LAN C are two separate
            departments with little inter-communication. They share servers
            attached to LAN B.
 o   FULLY-INTERCONNECTED AND LOOP CONFIGURATIONS

     A fully-interconnected configuration (mesh) provides alternate paths from
     each LAN segment to another.  Should a bridge or path fail, traffic can be
     routed through an alternate path, thereby increasing availability of the
     server segment.

     This solution tends to become impractical as the number of LAN segments
     grows.  For N LANs, one would require N(N-1)/2 bridges. Therefore, a loop
     configuration as shown in Figure 86 under heading "6.2.1.1.1  General
     Guidelines" can be an acceptable compromise between availability versus
     cost and complexity (18 under heading "6.2.1.1.1  General Guidelines").

 ---Footnote---
 (18) A loop configuration with three LAN segments is also fully-interconnected.
 --------------

 -------------------------------------------------------------------------------

           *-----------*           *-----------*
           ]           ]           ]           ]
           ]    LAN    ]   *---*   ]    LAN    ]
           ]           ]---]   ]---]           ]
           ]     A     ]   *---*   ]     B     ]
           ]           ]   Bridge  ]           ]
           *-----------*     1     *-----------*
                 ]                       ]
               *---* Bridge            *---* Bridge
               ]   ]   4               ]   ]   2
               *---*                   *---*
                 ]                       ]
           *-----------*           *-----------*
           ]           ]           ]           ]
           ]    LAN    ]   *---*   ]    LAN    ]
           ]           ]---]   ]---]           ]
           ]     D     ]   *---*   ]     C     ]
           ]           ]   Bridge  ]           ]
           *-----------*     3     *-----------*

 -------------------------------------------------------------------------------
 Figure 86. Loop Configuration with Four LANs
 o   PARALLEL BRIDGE CONFIGURATION

     Parallel bridges can address the problems of heavy traffic flows through
     particular bridges and/or high availability requirements.  While the
     failure of one bridge would impact connectivity between LAN segments over
     that bridge, sessions could be recovered via the parallel bridge.  In
     today's environment this would require that the application be
     re-initialized and the new route be discovered during that initialization
     process.
 -------------------------------------------------------------------------------

           *-----------*           *-----------*
           ]           ]           ]           ]
           ]           ]   *---*   ]           ]
           ]           ]---]   ]---]           ]
           ]    LAN    ]   *---*   ]    LAN    ]
           ]           ]   Bridge  ]           ]
           ]           ]     1     ]           ]
           ]     A     ]   *---*   ]     B     ]
           ]           ]---]   ]---]           ]
           ]           ]   *---*   ]           ]
           ]           ]   Bridge  ]           ]
           *-----------*     2     *-----------*

 -------------------------------------------------------------------------------
 Figure 87. Parallel Configuration
 o   BACKBONE LAN CONFIGURATION

     If growth is an important factor, a backbone LAN configuration can provide
     the necessary flexibility. It also offers common server and gateway access
     to a potentially very large number of LAN stations.

     In a backbone configuration a number of LAN segments, sometimes referred
     to as departmental LANs, are all connected to the same backbone LAN as
     shown in Figure 88 under heading "6.2.1.1.1  General Guidelines".  This
     implies that between any two LAN stations attached to departmental LANs,
     there is always a communications path that includes relatively few
     bridges, whatever the size of the bridged LAN.
 -------------------------------------------------------------------------------

        *---------*                   *---------*
        ] Host    ]                   ] Server  ]
        ] Gateway ]                   ] station ]
        *---------*                   *---------*
             ]                             ]
   *------------------------------------------------*
   ]                Backbone LAN                    ]
   *------------------------------------------------*
    *---*    *---*    *---*                   *---*
    ]B 1]    ]B 2]    ]B 3]                   ]B n]   Bridges
    *---*    *---*    *---*                   *---*
   *-----*  *-----*  *-----*                 *-----*
   ]LAN 1]  ]LAN 2]  ]LAN 3]................ ]LAN n]  Departmental LANs
   *-----*  *-----*  *-----*                 *-----*
    *---*    *---*    *---*
    ]B a]    ]B b]    ]B c]     Bridges
    *---*    *---*    *---*
   *-----------------------*
   ]                       ]
   ] Duplex Backbone LAN   ] or 3-LAN Loop configuration
   *-----------------------*

 -------------------------------------------------------------------------------
 Figure 88. Backbone LAN Configuration

     Because of the potentially high concentration of traffic on the common
     backbone LAN, a LAN segment with stable performance characteristics and
     possible higher bandwidth than the individual segments may be required.
     As explained in "2.2.1 Basic CSMA/CD Concepts" and "2.2.2 Basic
     Token-Passing Ring Concepts," a 4 or 16 Mbps Token-Ring Network may be a
     more desirable choice for a backbone LAN segment than a CSMA/CD LAN
     segment.

     As an example, the backbone LAN in Figure 88 under heading "6.2.1.1.1
     General Guidelines" could be a 16 Mbps IBM Token-Ring Network,
     interconnecting a mixture of IBM PC Network (Broadband) LANs and 4 Mbps
     IBM Token-Ring Networks.

     Because of high availability, backup and/or capacity considerations, one
     might consider implementing a duplex backbone, as a mirror image of the
     first one.

 6.2.1.1.2  Additional Design Considerations for Bridged LANs:  When designing
 a bridged LAN, one cannot ignore the bridge protocol implemented in the bridge
 products themselves.  Special attention may have to be paid to specific bridge
 parameters.
 The bridging technique discussed in "6.3.1 Transparent Bridging," does not
 allow concurrently active parallel bridges or parallel routes.
 For a more detailed discussion of LAN design considerations, please refer to
 IBM MULTISEGMENT LAN DESIGN GUIDELINES (GG24-3398).
 When using a source routing bridge protocol as presented in "6.3.2 Source
 Routing," one may want to consider bridge parameters called SINGLE ROUTE
 BROADCAST and HOP COUNT, to prevent flooding of the bridged network with
 control frames during route resolution.
 When selecting a particular configuration, the bridge performance itself
 should be considered in addition to the above factors.
 Bridge processing within a bridged local area network adds some degree of
 overhead to the overall network throughput. The amount of bridge overhead
 depends on several factors, some of which are listed below:
 o   FRAME SIZE: as the size of the frame increases, the bridge throughput
     increases.  Thus the largest possible frame size should be used, subject
     to the constraints of applications, memory or buffer management.
 o   BRIDGE HOP DELAY:  this is the elapsed time between the end of the receive
     stage for a frame entering the bridge, and the end of the transmit process
     for the same frame leaving the bridge through another port.  This time is
     seldom more than a few milliseconds, increasing as the frame size and LAN
     traffic loads increase, but potentially more important when the
     interconnected MAC protocols are different or run at different speeds.

 END-USER PERCEPTION of application delay may or may not be affected by bridge
 delays.  As a general guideline, with slower applications, such as those
 involving disk access or host access, bridge delays will not normally be
 perceived.  Other, faster applications such as program loads or
 memory-to-memory copies, may be impacted when the frames must cross one or
 more heavily used bridges.
 The following factors minimize the impact of the above delays:
 o   Frames flowing through a bridge may be given a higher traffic priority
     than normal LAN station frames, thus reducing the probability of bridge
     congestion due to token-wait time.
 o   Route selection (based upon source routing) where more than one path is
     possible, is based upon the fastest rather than the shortest path.
 In normal workload conditions, bridge processing does not constitute a
 bottleneck in a bridged LAN environment.
 The IBM bridge products provide performance monitoring information to assist
 in monitoring traffic flow and bridge performance.  See "6.6 IBM LAN Bridges."

 6.3  Bridge Standards
 Two different approaches to LAN bridging have been developed within the IEEE
 community. Both of these architectures will now be described, together with a
 new approach to solving the problem of inter-operability between the
 architectures.
 IBM included in its Token-Ring Architecture, see IBM TOKEN-RING NETWORK
 ARCHITECTURE REFERENCE a bridge architecture called SOURCE ROUTING, and
 developed products implementing this approach.  This approach has now been
 included in the IEEE 802.5 Standard.
  In parallel, the IEEE 802.1 subcommittee was working on a MAC bridge
 architecture called TRANSPARENT BRIDGING, which currently has the status of a
 Draft IEEE Standard.  As a requirement of the IEEE 802 committees, source
 routing must be capable of inter-operating with transparent bridging at the
 MAC level.

 6.3.1  Transparent Bridging
 This section describes the transparent bridging protocol and its associated
 spanning tree algorithm as drafted by the IEEE 802.1 subcommittee.
 In this bridge architecture, there is a clear distinction between the actual,
 physical bridged LAN topology and the simply connected active topology, which
 reflects use of a spanning tree algorithm.  Figure 89 under heading "6.3.1
 Transparent Bridging" shows the physical configuration of a sample bridged LAN
 as well as a possible active topology.
 +------------------------------------------------------------------------------
 ]
 ]              *-------------------------------------------------------*
 ]              ]                    LAN Segment 1                      ]
 ]              *-------------------------------------------------------*
 ]                     *---*             *---*              *---*
 ]                   *-] P ]-*         *-] P ]-*         *--] P ]--*
 ]                   ] *---* ]         ] *---* ]         ]  *---*  ]
 ]                   ]  BR5  ]         ]  BR1  ]       *---* BR2 *---*
 ]                   ] *---* ]         ] *---* ]     *-] P ]     ] P ]-*
 ]                   *-] P ]-*         *-] P ]-*     ] *-------------* ]
 ]                     *---*             *---*       ]                 ]
 ]                       ]                 ]         ]                 ]
 ]       *-------------------------------* ] *---------------* *---------------*
 ]       ]         LAN Segment 5         ] ] ] LAN Segment 3 ] ] LAN Segment 4 ]
 ]       *-------------------------------* ] *---------------* *---------------*
 ]             *---*           *---*       ]
 ]           *-] P ]-*       *-] P ]-*     ]
 ]           ] *---* ]       ] *---* ]     ]         P = Bridge Port
 ]           ]  BR3  ]       ]  BR4  ]     ]
 ]           ] *---* ]       ] *---* ]     ]         BRn = Bridge number n
 ]           *-] P ]-*       *-] P ]-*     ]
 ]             *---*           *---*       ]
 ]       *-----------------------------------------*
 ]       ]             LAN Segment 2               ]
 ]       *-----------------------------------------*
 ]
 ]               BRIDGED LAN - PHYSICAL TOPOLOGY
 ]
 ]
 ]              *-------------------------------------------------------*
 ]              ]                    LAN Segment 1                      ]
 ]              *-------------------------------------------------------*
 ]                     *---*             *---*              *---*
 ]                   *-] P ]-*         *-] P ]-*         *--] P ]--*
 ]                   ] *---* ]         ] *---* ]         ]  *---*  ]
 ]                   ]  BR5  ]         ]  BR1  ]       *---* BR2 *---*
 ]                   ] *---* ]         ] *---* ]     *-] P ]     ] P ]-*
 ]                   *-] P ]-*         *-] P ]-*     ] *-------------* ]
 ]                     *---*             *---*       ]                 ]
 ]                                         ]         ]                 ]
 ]       *-------------------------------* ] *---------------* *---------------*
 ]       ]         LAN Segment 5         ] ] ] LAN Segment 3 ] ] LAN Segment 4 ]
 ]       *-------------------------------* ] *---------------* *---------------*
 ]             *---*           *---*       ]
 ]           *-] P ]-*       *-] P ]-*     ]
 ]           ] *---* ]       ] *---* ]     ]         P = Bridge Port
 ]           ]  BR3  ]       ]  BR4  ]     ]
 ]           ] *---* ]       ] *---* ]     ]         BRn = Bridge number n
 ]           *-] P ]-*       *-] P ]-*     ]
 ]             *---*           *---*       ]
 ]       *-----------------------------------------*
 ]       ]             LAN Segment 2               ]
 ]       *-----------------------------------------*
 ]
 ]               BRIDGED LAN - ACTIVE TOPOLOGY
 +------------------------------------------------------------------------------
 Figure 89. Bridged LAN - Physical and Active Topologies.
 In an active topology, frames are forwarded through those bridge ports which
 are said to be in FORWARDING state.  Other bridge ports do not forward frames
 and are held in BLOCKING state.  Bridges only connect LAN segments to which
 they have attached ports in forwarding state.  A port in blocking state may be
 put in forwarding state, that is become part of the active topology, if bridge
 components fail, are removed or are added.
 In an active topology, one bridge is known as the ROOT BRIDGE. Each LAN
 segment has a bridge port connected to it, called the DESIGNATED PORT, which
 forwards frames from that segment to the root (bridge).   The bridge to which
 the designated port for a particular LAN segment belongs is called the
 DESIGNATED BRIDGE.  The root bridge is implicitly the designated bridge for
 all the LAN segments to which it is connected.  At any particular bridge, the
 root port and the designated ports, if any, are the ports in forwarding state.
 As an example, bridge 1 in the active topology sample presented in Figure 89
 under heading "6.3.1  Transparent Bridging" has been selected as the root
 bridge.  Therefore it is the designated bridge for LAN segments 1 and 2.
 Bridge 2 is the designated bridge for LAN segments 3 and 4, while bridge 4 is
 the designated bridge for LAN segment 5.  This structure can be represented as
 a logical tree topology, called a SPANNING TREE, as shown in Figure 90 under
 heading "6.3.1  Transparent Bridging".
 +------------------------------------------------------------------------------
 ]
 ]                                 *---------------------*
 ]                                 ]      Bridge 1       ]
 ]                                 ] Id 42     R-P-C 00  ]
 ]                                 ] *- - - -* *- - - -* ]
 ]                                 *-]P-Id 01]-]P-Id 02]-*
 ]                                   ]Cost 10] ]Cost 10]
 ]                                   *-------* *-------*
 ]                                       ]         ]
 ]         *---------------------------------* *--------------------------------
 ]         ]         LAN Segment 1           ] ]         LAN Segment 2
 ]         *---------------------------------* *--------------------------------
 ]               ]                 ]                 ]                     ]
 ]           *-------*         *-------*         *-------*             *-------*
 ]           ]P-id 01]         ]P-Id 02]         ]P-id 01]             ]P-id 01]
 ]         *-]Cost 05]-* *-----]Cost 10]-----* *-]Cost 05]-*         *-]Cost 05]
 ]         ] *- - - -* ] ]     *- - - -*     ] ] *- - - -* ]         ] *- - - -*
 ]         ] Bridge 5  ] ]     Bridge 2      ] ] Bridge 5  ]         ] Bridge 4
 ]         ] Id 83     ] ]Id 97     R-P-C 10 ] ] Id 83     ]         ] Id 57
 ]         ] R-P-C 05  ] ]*- - - -* *- - - -*] ] R-P-C 05  ]         ] R-P-C 05
 ]         ] *- - - -* ] *]P-Id 01] ]P-Id 03]* ] *- - - -* ]         ] *- - - -*
 ]         *-]P-Id 02]-*  ]Cost 05] ]Cost 05]  *-]P-Id 02]-*         *-]P-Id 02]
 ]           ]Cost 05]    *-------* *-------*    ]Cost 05]             ]Cost 05]
 ]           *-------*        ]         ]        *-------*             *-------*
 ]                            ]         ]                                  ]
 ]         *----------------------* *----------------------* *------------------
 ]         ]    LAN Segment 3     ] ]    LAN Segment 4     ] ]   LAN Segment 5
 ]         *----------------------* *----------------------* *------------------
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 90. Spanning Tree Sample
 Abbreviations in this figure have the following meanings:
 o   Bridge:
     -   Id = Bridge identifier (unique throughout bridged LAN)
     -   R-P-C = Root path cost (least-cost path between root and bridge port)
 o   Port:
     -   P-Id = Port identifier (associated with each bridge port)
     -   Cost = Path cost (default value is related to the type of the attached
         LAN segment)
 The active topology is described in a FILTERING DATABASE, containing static
 and dynamic entries. STATIC ENTRIES are entered under explicit management
 control and contain MAC addresses for which filtering is specified as well as
 a port map that specifies the state (forwarding or blocking) of each port.
 The following parameters are examples of static entries which, amongst others,
 determine the active topology:
 o   Unique bridge identifiers
 o   The path cost for each bridge port
 o   The port identifier associated with each bridge port.
 DYNAMIC ENTRIES result from a learning process through communication with
 other bridges or LAN stations to take into account physical LAN configuration
 changes.  Dynamic entries also change whenever the active topology changes
 (such as the result of updated path cost values).  A dynamic entry contains a
 MAC address for which filtering is specified and a port number to which frames
 with the specified destination address are to be forwarded.
 The filtering database may be initialized with static entries from a permanent
 database.
 Bridges exchange BRIDGE PROTOCOL DATA UNITS (BPDUs) to propagate topology
 information, thereby enabling computation of the active topology and resulting
 spanning tree.  A frame containing a BPDU has a "functional address" as its
 MAC destination address.  This forces all active bridges connected to the same
 LAN segment as the sending bridge to copy the BPDU information. The
 information carried in the BPDU supports selection of the designated port for
 the LAN segment (the one with the lowest root path cost).  At the same time,
 it allows any bridge to select from its designated ports the one which is the
 closest (that is, lowest cost) to the root as its ROOT PORT.  The root bridge
 is the bridge with the highest priority bridge identifier.
 Thus selection of the active topology of a bridged LAN can be managed by
 setting proper values for bridge identifier (priority component), for path
 cost and for port identifier for each bridge port.
 Because of propagation delays involved in communicating control information, a
 sharp transition from one active topology to another one is not possible.
 Therefore wait times are provided by the protocol as well as intermediate port
 states.  Consequently, apart from being in disabled, blocking or forwarding
 state, a port can be in listening or learning state.  A port in blocking state
 must enter listening state, followed by learning state before entering into
 forwarding state (that is before actually participating in frame relay).
 A very important implication of transparent bridging with its particular
 spanning tree algorithm, is that one cannot have concurrently active parallel
 bridges (interconnecting the same two LAN segments) or even concurrently
 active parallel paths (interconnecting the same source and destination LAN
 segments).

 6.3.2  Source Routing
 Source routing refers to the route-resolution architecture and protocols as
 implemented in the IBM bridge products, and as described in the IBM TOKEN-RING
 NETWORK ARCHITECTURE REFERENCE.
 A route through a multi-segment LAN can be described as a sequence of SEGMENT
 NUMBERS and BRIDGE NUMBERS.  A segment number - bridge number combination is
 called a ROUTE DESIGNATOR.
 Therefore, before looking at the route-resolution mechanisms used in source
 routing, Figure 91 under heading "6.3.2  Source Routing" shows how ROUTING
 INFORMATION is carried within a token-passing ring frame, and how route
 designators are entered in the RI field.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                                     <-----I----->
 ]     *------------------------------------------------------------*
 ]     ] SD ] AC ] FC ]  DA   ]  SA   ] RI ]        ] FCS ] ED ] FS ]
 ]     *------------------------------------------------------------*
 ] I/G                    ]       ]      ]
 ] *--------------------* ]       ]      ]
 ] ]X] Destination Addr ]-*       ]      ]
 ] *--------------------*         ]      ]
 ] *--------------------*         ]      ]
 ] ]X] Source Address   ]---------*      ]
 ] *--------------------*                ]
 ]  Routing                              ]
 ]  Indicator      <---------------------- 18 Bytes -------------------->
 ]                 <---2---> <-----2---->
 ]                *--------------------------------------/---------------*
 ]                ] ROUTING ]   ROUTE    ]   ROUTE    ]     ]   ROUTE    ]
 ]                ] CONTROL ]DESIGNATOR 1]DESIGNATOR 2]     ]DESIGNATOR 8]
 ]                *--------------------------------------/---------------*
 ]                     ]                       ]
 ]    *---------------------------------*      ]*- RN  (16 - k) bits
 ]     0             7   0             7       *]   *- unique Ring Nbr.
 ]    *---------------* *---------------*       *- IB , k bits
 ]    ]B]B]B]L]L]L]L]L] ]D]F]F]F]r]r]r]r]           *- Individual Bridge
 ]    *---------------* *---------------*              nbr., unique for
 ]       ]       ]       ]   ]     ]                   parallel bridges
 ]       ]       ]       ]   ]     *- reserved
 ]       ]       ]       ]   *- Largest Frame
 ]       ]       ]       *- Direction bit
 ]       ]       *- Length of RI (5 bits)
 ]       *- Broadcast Indicators
 ]
 +------------------------------------------------------------------------------
 Figure 91. Token Passing Ring Frame - Routing Information Field
 Figure 92 under heading "6.3.2  Source Routing" lists the control bit settings
 involved in source routing.
 +------------------------------------------------------------------------------
 ]
 ]
 ]   *------------------------------------------------------------------*
 ]   ]Largest ] size  ] comments                                        ]
 ]   ]Frame   ](bytes)]                                                 ]
 ]   ]--------+------ +-------------------------------------------------]
 ]   ] B'000' ]  516  ] I-field, min. for LLC Type 1 operation          ]
 ]   ] B'001' ] 1500  ] largest frame size supported in ISO 8802-3 LANs ]
 ]   ] B'010' ] 2052  ] suitable for 24 x 80 full screen data xfer      ]
 ]   ] B'011' ] 4472  ] largest frame size supported in FDDI draft and  ]
 ]   ]        ]       ] in ISO 8802-5 LANs with T(Token_Holding) = 9ms  ]
 ]   ] B'100' ] 8191  ] largest frame size supported in ISO 8802-4 LANs ]
 ]   ] B'101' ]       ] reserved                                        ]
 ]   ] B'110' ]       ] reserved                                        ]
 ]   ] B'111' ]       ] used in all-routes broadcast frames             ]
 ]   ]------------------------------------------------------------------]
 ]   ]Broadcast]designator   ] comments                                 ]
 ]   ]---------+-------------+------------------------------------------]
 ]   ] B'0XX'  ]Non-broadcast] used in local or specific route frames   ]
 ]   ] B'10X'  ]All-routes   ] frame transmitted along every route      ]
 ]   ]         ] Broadcast   ] in the network to the destination station]
 ]   ] B'11X'  ]Single-route ] only designated bridges will relay the   ]
 ]   ]         ] Broadcast   ] frame from one segment to the other      ]
 ]   ]------------------------------------------------------------------]
 ]   ]Route        ]length] comments                                    ]
 ]   ]Designator   ](bits)]                                             ]
 ]   ]-------------+------+---------------------------------------------]
 ]   ] Ring-Number ] 16-k ] k is the same for all bridges in one        ]
 ]   ] Individual- ]   k  ] multi-ring LAN, typically k = 4 (Bridge V1) ]
 ]   ]  Bridge-Nr. ]      ]                                             ]
 ]   *------------------------------------------------------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 92. Routing Information Field - Code Bits
 SOURCE ROUTING is started at session connect time by the DLC_LAN_MGR (data
 link control LAN manager) component of a station taking actions to RESOLVE THE
 ROUTE
 Route resolution is usually a two-stage process, whereby first the destination
 station is searched on the LOCAL LAN SEGMENT.  If the destination cannot be
 located on the local segment, the destination will be searched on remote
 segments connected via bridges.
 o   On-segment route determination:  the source station sends a TEST or an
     IEEE 802.2 XID command LLC protocol data unit (LPDU) to the address of the
     destination without any routing information.  The destination, if present,
     responds with a TEST or XID response LPDU.  If no response LPDU is
     returned within a specific amount of time, the destination address is
     assumed not to be on the local LAN segment, and the second stage of the
     route discovery is initiated.
 o   Off-segment route determination:  the source station immediately
     retransmits the TEST or XID LPDU, indicating however the presence of
     routing information by setting byte 0, bit 0 of the source address field
     to 1 and appending an initial 2-byte RI field after the Source Address
     field (see Figure 91 under heading "6.3.2  Source Routing").  At this
     point the architecture provides a choice between two main dynamic route
     discovery processes: ALL-ROUTES BROADCAST ROUTE DETERMINATION and
     SINGLE-ROUTE BROADCAST ROUTE DETERMINATION.

 6.3.2.1.1  All-Routes Broadcast Route Determination:  In a TEST or XID command
 LPDU, broadcast to all rings by the source station, the first two bits of the
 RI field are set to B'10'. This triggers all bridges to copy the LPDU frame,
 based on Hop Count limitations set at the bridge, and while forwarding it, to
 complete the RI field with additional route designator information.
 The destination station receives as many command LPDUs as there are available
 routes, while any received frame contains in its routing information field the
 precise route which has been followed.  Any received command LPDU will be
 returned as a response LPDU, setting the first RI-bit to B'0' (non-broadcast)
 and another routing control bit, the direction bit, to B'1'. This forces any
 response frame to flow back to the source station via the route as built in
 the LPDU of the command received.
 The source station selects the PREFERRED ROUTE from all returned response
 LPDUs, and subsequent transmissions to the destination station follow the
 preferred route.  The destination learns the preferred route from the first
 non-broadcast frame received from the partner source station.  The preferred
 route information between two stations remains valid for the duration of the
 DLC session between both.

 6.3.2.1.2  Single-Route Broadcast Route Determination:  A value of B'11' in
 the first two bits of the RI field, marks the TEST or XID command LPDU as a
 Single-Route Broadcast frame. Depending on the setting of the single-route
 broadcast bridge parameter (see "6.6 IBM LAN Bridges"), the bridge will decide
 whether or not to copy and forward the frame (leaving the RI-field unchanged).
 In this way, each LAN segment may communicate only one copy of the TEST or XID
 command LPDU and the destination station will receive only one command LPDU.
 The TEST or XID command LPDU is then returned as a response LPDU with the
 first two RI-bits indicating all-routes broadcast.  Again multiple response
 LPDUs may be received by a source station, but in this case routing
 information has been collected in the response flow rather than the command
 flow.
 As in the first procedure, the source station selects the PREFERRED ROUTE from
 all returned response LPDUs.
 Single route broadcast at the bridge level may be set on or off at bridge
 initialization time by a (controlling) LAN Manager.  If all bridges in a LAN
 are configured for automatic single-route path maintenance the active topology
 will be dynamically maintained by the bridges.  Alternatively, the
 single-route broadcast specification may be defined as a manual setting.  If
 so defined and the path becomes unavailable for any reason, the LAN Manager
 must take appropriate action to (manually) define an alternate path by
 reconfiguring the bridge's Single-Route broadcast setting.
 The dynamic single-route broadcast path maintenance option uses a spanning
 tree algorithm to maintain the status of each participating bridge.  Section
 "6.6.1 IBM Token-Ring Bridges" explains how this option is made available in
 the IBM Token-Ring Network Bridge Program V2.0, IBM Token-Ring Network Bridge
 Program V2.1, butler2. and IBM PC Network Bridge Program products.

 6.3.3  Source Routing/Transparent Bridging Inter-operability
 As stated earlier in this chapter ("6.3 Bridge Standards"), a requirement of
 the IEEE 802.1 committee has been that source routing bridges/stations must be
 capable of inter-operating with transparent bridges/stations, that is, bridges
 and stations that are not capable of interpreting routing information carried
 within frames.  Proponents of the two schemes have argued the benefits of both
 approaches to bridging, while the standards for their operation have been
 developed by two sub-committees within the IEEE.
 o   Source routing. IEEE 802.5, moving towards an International Standard as an
     addendum to ISO 8802.5
 o   Transparent Bridging. IEEE 802.1 Part D, now a Draft International
     Standard, DIS 10038, and widely accepted.
 Much discussion has centered around an annex to DIS 10038 that would solve the
 problem of inter-operability, but progress has been slow.
 One of the problems is that the implications of the two techniques are not
 only seen in the design and operation of the bridge itself; but also in the
 impact on the end-stations that need to communicate. For instance, stations
 that wish to use source routing have to make decisions on when to send
 Single-Route or All-Routes Broadcast frames, as well as interpreting the
 routing information field within the frame.  Not all stations do this,
 particularly those that are attached to networks that traditionally use
 transparent bridging.
 There may be occasions when, of the two stations that need to communicate, one
 will understand source routing, the other will not.  The goal of
 inter-operability is not achieved.
 In the bridge machines themselves, transparent bridges maintain tables of MAC
 addresses in order to make decisions as to when to forward frames. Source
 routing bridges build the routing information field and then use it to make
 their forwarding decision.  A source routing bridge will not forward frames
 that do not contain routing information; frames from non-source routing
 stations will not carry such information.
 At a March 1990 meeting of the IEEE 802 committees, IBM proposed the idea of a
 Source Routing Transparent (SRT) bridge that would solve these problems. An
 SRT bridge would be based on the concept of the transparent bridge, but would
 include source routing capability as a tower on top of the base function.
 An SRT bridge would form a single spanning tree with all other SRT and
 existing "standard" transparent bridges, and if the spanning tree allowed,
 would forward frames that did not contain a Routing Information field.  This
 would create a network identical in appearance and topology to that provided
 by today's transparent bridges.
 However, if a frame contained routing information, it would be forwarded in
 the same way as that understood for the source routing bridges of today, even
 if the bridge were in blocking state from the point-of-view of the spanning
 tree.
 SRT stations, stations that support both kinds of routing, would be able to
 utilize a source routing path if it existed (all bridges between the stations
 respective segments were SRT) or alternatively fall back on the spanning tree
 path.
 Figure 93 under heading "6.3.3  Source Routing/Transparent Bridging
 Inter-operability" shows a network that is made up of transparent bridges
 linking the LAN segments, and two workstations, X and Y, that need to
 communicate. Neither X nor Y understand routing information, so therefore must
 use the spanning tree path. This might create a bottleneck on bridges 1 and 2
 as well as segment A, since all traffic between stations on segments B, C and
 D will have to pass this way when bound for segments E, F, G and H.
 There is of course, a much shorter path between segments D and F, via Bridge
 8. However, the spanning tree has left this bridge in blocking state.
 Therefore it will not be used to forward frames, until in this case, bridge 4
 fails.

 -------------------------------------------------------------------------------

        *---*
        ]Seg]
        ] A ]
        *---*
      1*-* ]2
       ]   *--------------*
     *---*              *---*
     ]Seg]              ]Seg]
     ] B ]              ] E ]
     *---*              *---*
      ] ]           5*---*]*--------------*7
  3*--* *--*4        ]   6*----*          ]
   ]       ]       *---*     *---*      *---*
 *---*   *---*     ]Seg]     ]Seg]      ]Seg]
 ]Seg]   ]Seg] -8- ] F ]     ] G ]      ] H ]
 ] C ]   ] D ]     *---*     *---*      *---*
 *---*   *---*       ]
           ]  *---*  ]  *---*
           *--]W/S]  *--]W/S]
              ] X ]     ] Y ]
              *---*     *---*

 All bridges (numeric) are transparent bridges.
 LAN segments are denoted alphabetically.
 Bridge 8 exists, but is in 'blocking' state.
 W/S X and W/S Y do not "understand" routing information.

 For W/S X, path to W/S Y is via D,4,B,1,A,2,E,5,F.

 -------------------------------------------------------------------------------
 Figure 93. Transparent Bridging
 In Figure 94 under heading "6.3.3  Source Routing/Transparent Bridging
 Inter-operability", Bridge 8 has been replaced by an SRT bridge.  Although
 still in blocking state according to the spanning tree, it is able to pass
 frames that contain routing information. So, if the two workstations are able
 to interpret and use routing information, that is are SRT stations, they can
 now communicate on the direct path, D,8,F, saving the traffic overhead on the
 previously intervening segments and bridges.
 -------------------------------------------------------------------------------

        *---*
        ]Seg]
        ] A ]
        *---*
      1*-* ]2
       ]   *--------------*
     *---*              *---*
     ]Seg]              ]Seg]
     ] B ]              ] E ]
     *---*              *---*
      ] ]           5*---*]*--------------*7
  3*--* *--*4        ]   6*----*          ]
   ]       ]       *---*     *---*      *---*
 *---*   *---*     ]Seg]     ]Seg]      ]Seg]
 ]Seg]   ]Seg]--8--] F ]     ] G ]      ] H ]
 ] C ]   ] D ]     *---*     *---*      *---*
 *---*   *---*       ]
           ]  *---*  ]  *---*
           *--]W/S]  *--]W/S]
              ] X ]     ] Y ]
              *---*     *---*

 Bridges 1 - 7 are transparent bridges.
 Bridge 8 is an SRT bridge.

 Bridge 8 is in 'blocking' state as a transparent bridge, but will
 forward frames that include routing information.

 If W/S X and W/S Y both "understand" routing information, that is, are
 SRT stations, then path is D,8,F. There is a source routing path.

 Otherwise, route is D,4,B,1,A,2,E,5,F.

 -------------------------------------------------------------------------------
 Figure 94. An SRT Bridge in the Network
 For today's source routing stations, minor changes in behavior would be
 required to make them SRT stations.  For instance, during route discovery, a
 source routing station may transmit a Single-Route Broadcast frame.  Releases
 of the IBM Token-Ring Bridge Program Version 2, use a the standard
 inter-bridge spanning tree protocol, to build a single-route broadcast path.
 SRT bridges would be part of the "standard" spanning tree, as described by DIS
 10038, so if a station transmitted a frame with no routing information (frame
 now known as a ROUTE EXPLORER frame), that frame would arrive on each segment
 of the LAN once.  This achieves the same objective as the single-route
 broadcast path, so therefore frames normally sent single-route broadcast would
 simply be sent with no routing information and traverse the spanning tree.
 Non-SRT stations would send the ROUTE EXPLORER  response without routing
 information, and future inter-station communication would be over the spanning
 tree path.
 SRT stations would transmit the response frame twice, once with no routing
 information field, and once as a source routing All-Routes Broadcast frame.
 At least one of these frames would get back to its destination, and the a
 choice could be made on whatever route was available or most appropriate to be
 used.
 Group addressed frames currently sent single-route broadcast would be treated
 the same way, that is sent without the routing information field present.
 SOURCE ROUTING AND TRANSPARENT BRIDGING HARMONY IS OBTAINED.
 It also means that all the benefits of source routing, such as parallel
 bridges between segments, could be realized, without impacting the operation
 of the spanning tree.
 One of the other benefits of this approach is that one of the problems of
 bridge and station inter-operability over other LAN types, such as FDDI, is
 also solved. Any LAN implementation, present or future, needs only to add the
 capability to support a routing information field in its MAC frame, and all
 attaching stations, whether attaching directly or indirectly to that network,
 supporting routing information fields or not, will be able to communicate
 using one path or another.
 It is no wonder this concept has been hailed as a breakthrough by all
 concerned, and is rapidly moving forward within the standards arena.
 By use of this approach, the best of both worlds is achieved.  The two
 techniques build upon each other.  Customers will be able to build their
 networks to use the benefits of source routing bridges where they feel
 appropriate.
 The techniques of the SRT bridge/station have little impact on the existing
 "standards" work, in fact they make it considerably easier.  However, it must
 be remembered that the SRT bridging concept is only at the preliminary stages
 of the "standardization" process.  The enthusiasm with which the idea has been
 received may mean that in the future, an SRT bridge product, implemented in
 accordance with an international standard, may find its way to the market.

 6.4  Bridge LAN Management Interface
 IBM Token-Ring bridges have server components built into them that are used
 for management purposes. These server components are able to use another
 component called the LAN Reporting Mechanism  (LRM) to establishing a
 reporting link with up to four IBM LAN Managers or IBM LAN Network Managers.
 Each reporting link is an IEEE 802.2 logical link control Type 2
 (connection-oriented) link, dedicated to transport network management
 information in either direction.
 LAN management functions and products are discussed in a separate Chapter "9.0
 LAN Management and Recovery."  Some LAN management commands change the way in
 which a LAN segment operates. When a bridge has a reporting link with several
 IBM LAN Managers to control the same LAN segment, those commands must be
 reserved to one LAN Manager only to avoid conflicts. This LAN Manager is
 called the CONTROLLING LAN MANAGER for a given bridge. All other (up to three)
 LAN Managers to which this bridge reports are called OBSERVING LAN MANAGERS.
 The setting of a reporting link in the IBM LAN Management products is done at
 initialization time.  Any given IBM LAN Management product can have one, and
 only one, reporting link specification.
 The link between a bridge and its controlling LAN Manager is reporting link 0,
 also referred to as authorization level 0.  Once a reporting link 0 is
 established, bridges reject subsequent attempts by other IBM LAN Managers to
 establish a reporting link 0, thereby avoiding duplicate controlling LAN
 Managers.
 Observing LAN Managers have reporting links 1, 2 or 3 with a given bridge.
 IBM Token-Ring bridges may receive requests from the IBM LAN Manager or IBM
 LAN Network Manager, and send back appropriate responses over a reporting link
 after executing the request on an attached ring segment.
 Some of the commands can only be executed when they are received on reporting
 link 0, that is from the controlling LAN Manager. These commands are:
 o   Set single-route broadcast in a bridge.
 o   Remove station on a ring segment.
 o   Set soft error logging options for a ring segment.
 o   Perform a path test (this command has been removed from LAN Network
     Manager).
 The communication between IBM LAN Management products and IBM Token-Ring
 Network Bridge Program V2 is shown in Figure 95 under heading "6.4  Bridge LAN
 Management Interface".
 +------------------------------------------------------------------------------
 ]
 ]
 ]               Observing   Controlling   Observing    Observing
 ]LAN Managers   *-------*    *-------*    *-------*    *-------*
 ]               ]       ]    ]       ]    ]       ]    ]       ]
 ]               ]   .   ]    ]   *   ]    ]   .   ]    ]   .   ]
 ]               *---.---*    *---*---*    *---.---*    *---.---*
 ] Reporting Links   3            0            2            1
 ] (LLC Type 2)      ...........  *        .....            .
 ]                             .  ****     .     ............
 ]Bridge Program *-------------.-----*-----.-----.--------------*
 ]               ]      *------.-----*-----.-----.------*       ]
 ]               ]      ]    ] * ] ] * ] ] * ] ] * ]    ]       ]
 ]               ]      ]    *---* *---* *---* *---*    ]       ]
 ]               ]      ] LAN Reporting Mechanism (LRM) ]       ]
 ]               ]      *-------------------------------*       ]
 ]               ]         ]       ]       ]        ]           ]
 ]               ]      *-----* *-----* *-----* *-------*       ]
 ]               ]      ] REM ] ] RPS ] ] CRS ] ]  LBS  ]       ]
 ]               ]      *-----* *-----* *-----* *-------*       ]
 ]               ]         ]       ]       ]        ]           ]
 ]               ]      *-------------------------------*       ]
 ]               ]      ]         MAC Router            ]       ]
 ]               ]      *-------------------------------*       ]
 ]               ]                                              ]
 ]               ]          *------------------------*          ]
 ]               ]          ]     Bridge Task        ]          ]
 ]               *----------------------------------------------*
 ]                 ]Token-Ring Adapter]    ]Token-Ring Adapter]
 ]                 *------------------*    *------------------*
 ]    Ring Segments         ]                        ]
 ]               *--------------------*    *--------------------*
 ]               ]   -------------*   ]    ]         -------*   ]
 ]     *----*    ]                ]   ]    ]                ]   ]   *----*
 ]     ] A  ]----]     Ring XXX   ]   ]    ]     Ring YYY   ]   ]---]  B ]
 ]     *----*    ]                ]   ]    ]                ]   ]   *----*
 ]       ]       ]          <-----*   ]    ]          <-----*   ]      ]
 ]               *--------------------*    *--------------------*
 ]       * - - - - - - - - LAN application LLC session - - - - - - - - *
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 95. IBM Token-Ring Network Bridge Program V2 - IBM LAN (System) Manager
            Communication
 This figure summarizes both the application flow between end stations
 (carrying data and higher-level-protocol header information), and network
 management data flow.  The latter consists of LLC Type 2 sessions between LAN
 Manager and the LAN reporting mechanism which directs a LAN Manager
 request/command to the appropriate server function in the Bridge.  On the ring
 segments side, LAN Manager requests/commands are translated into the
 appropriate MAC frames for execution on one of the two attached ring segments.
 Responses provided by the appropriate server function are directed to the LAN
 reporting mechanism which packages them into an LLC frame addressed to the
 originating LAN Manager.
 Various server functions are also illustrated.  Some of these, associated with
 network management, are optional, while the LAN Bridge Server is always
 present.
 LAN BRIDGE SERVER
 The bridge processing by the LBS function consists of:
 o   Reading and validating bridge parameters from a configuration file at
     bridge initialization time and whenever a controlling LAN Manager modifies
     bridge parameters.
 o   Performing the bridge self-test during bridge initialization or upon
     request from an operator through the bridge user interface.  This test
     includes detection of duplicate parallel paths and invalid network
     configurations (that is inconsistent ring numbering).
 o   Maintaining a set of performance counters for each adapter, including
     counters for the number of frames discarded, not received or not forwarded
     for any other reason, and for the number of frames and bytes forwarded
     (both for broadcast and non-broadcast frames).  On request, the
     accumulated values may be reported to LAN Manager.
 o   Accumulating path trace information for frames carrying a system path
     trace bit set on in the routing information control field.  Path trace
     report frames may be sent to the controlling LAN Manager.
 The different bridge server functions which may be enabled optionally on each
 of the bridge token-ring adapters are also shown in Figure 95 under heading
 "6.4  Bridge LAN Management Interface".
 RING ERROR MONITOR
 The REM server function in the bridge compiles error statistics from received
 Soft_ Error_ Report MAC frames and selectively generates reports for LAN
 Manager, depending on the SOFT ERROR REPORTING MODE (normal/intensive) set by
 LAN Manager.
 RING PARAMETER SERVER
 The Ring Parameter Server (RPS) is the target for all Request Initialization
 MAC frames that are sent by ring stations during their attachment to the ring
 segment.  The RPS function makes the following parameters available to all
 ring stations on the ring in response to the Request Initialization MAC frame:
 o   Ring Number
 o   Ring Station Soft Error Report Timer value (default of 2 seconds)
 o   Physical location (not currently implemented)
 There can be more than one RPS function active on any give ring segment.
 CONFIGURATION REPORT SERVER
 The CRS function forwards configuration notifications to LAN Manager.  Upon
 receipt of a MAC level configuration notification, it transmits the received
 information via the LAN reporting mechanism to LAN Manager. From LAN Manager,
 CRS accepts such commands as Query Adapter, Remove Adapter and Set Station
 Parameters for execution on a bridge-attached LAN segment.

 6.5  Remote Bridge
 A REMOTE BRIDGE, also called a split bridge, is a bridge which interconnects
 LAN segments using a telecommunication link for the transmission of frames
 between bridge ports, as conceptually shown in Figure 96 under heading "6.5
 Remote Bridge".
 +------------------------------------------------------------------------------
 ]
 ]*-----------*                                             *-----------*
 ]]           ]  <------       Split Bridge        ------>  ]           ]
 ]]           ]  *-----*                                    ]           ]
 ]]           ]  ]]   ]]W1                         *-----*  ]           ]
 ]] Ring N    ]---]   ]---------------/            ]]   ]]P2]           ]
 ]]           ]P1]]   ]]          WAN/--------------]   ]---] Ring M    ]
 ]]           ]  *-----*                         W2]]   ]]  ]           ]
 ]]           ]                                    *-----*  ]           ]
 ]*-----------*            P1 = bridge port 1               ]           ]
 ]                         P2 = bridge port 2               ]           ]
 ]                    W1 = WAN communications port 1        ]           ]
 ]                    W2 = WAN communications port 2        *-----------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 96. Remote Bridge Concept
 Physically, a remote bridge consists of two halves at each side of the
 communications link. Instead of regular frame forwarding from one LAN adapter
 to the other one as in a normal or local bridge, in a remote bridge a frame is
 copied in one station from the LAN adapter to the communications adapter
 (adding source routing information as required).  This communications adapter
 sends the frame across the communications link to the peer communications
 adapter in the other bridge half, where the LLC frame is copied to the second
 LAN adapter and transmitted on its LAN segment.
 Functionally, a remote bridge provides logical link control level end-to-end
 connectivity between LAN stations on either side of the bridge, supporting any
 higher layer protocol carried over the LLC link.  In contrast, a typical
 remote gateway solution as offered by a remote System/370 host gateway device
 supports only its own higher-level protocols, for example, LU1, LU2 and LU6.2,
 between a LAN station and a System/370 main frame.
 IBM provides remote bridge support in the IBM Token-Ring Network Bridge
 Program V2.1 and V 2.2 products.  This implementation is described in greater
 detail in "6.6.1 IBM Token-Ring Bridges."

 6.6  IBM LAN Bridges
 IBM local area network bridges are implemented in dedicated machines attached
 to two different LAN segments. For IBM Token-Ring Network Bridge Program V2
 and IBM PC Network Bridge Program the bridge machine is a dedicated Personal
 Computer or Personal System/2 workstation containing two LAN adapters,
 (appropriate for the type of attached LAN segment), and a bridge program
 running in the workstation's memory.
 Since the bridge workstation is entirely dedicated to the bridging function,
 these IBM Bridge Programs operate in a single-task IBM PC/DOS 3.3 or 4.0
 environment.
 The IBM 8209 LAN Bridge runs in stand-alone machines that do not require
 PC/DOS support.
 IBM bridges support source routing as described in "6.3.2 Source Routing."
 Since the routing information field can only contain up to eight route
 designators, end stations in a multi-segment environment communicate over a
 maximum of seven source-routing bridges.
 Communication across any IBM bridge is transparent to applications written to
 the IEEE 802.2 logical link control.
 The original bridge program, the IBM Token-Ring Network Bridge Program Version
 1.0, is no longer marketed.  This product supported interconnection of two 4
 Mbps token-ring segments.  It was succeeded by IBM TOKEN-RING NETWORK BRIDGE
 PROGRAM V1.1, which also supports two 4 Mbps token-ring segments.  In
 addition, IBM Token-Ring Network Bridge Program V1.1 can communicate with up
 to four LAN Managers implemented by IBM LAN Manager V1.0.  Network management
 aspects will be covered in greater detail in "9.1 IBM's Total Network
 Management Strategy" .
 The most recent IBM token-ring network bridge implementations are the IBM
 Token-Ring Network Bridge Program V2.2 and IBM PC Network Bridge Program.
 When all bridges in the network are running either IBM Token-Ring Network
 Bridge Program V2 or IBM PC Network Bridge Program and are configured
 appropriately, they will communicate with each other to automatically
 configure the network single-route broadcast path. Refer to the single route
 broadcast route determination algorithm in section "6.6.1.1.1.1 Single-Route
 Broadcast Path Maintenance" for an introductory discussion of this
 route-resolution technique.
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.0

           The IBM Token-Ring Network Bridge Program V2.0 interconnects
           token-ring segments operating at either 4 Mbps or 16 Mbps. IBM
           Token-Ring Network Bridge Program V2.0 communicates with up to four
           LAN managers implemented by IBM LAN Manager V2.0.
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.1

           The IBM Token-Ring Network Bridge Program V2.1 was the first release
           to provide REMOTE BRIDGING.  It includes all the functions and
           capabilities of IBM Token-Ring Network Bridge Program V2.0, and
           provides bridging functions between remote token-ring segments (4
           Mbps or 16 Mbps) over a leased teleprocessing (TP) line operating at
           speeds from 9.6 Kbps to 1.344 MBps. In this case, a LAN workstation
           at each end of the TP link will implement one half of the remote
           bridge.

           IBM Token-Ring Network Bridge Program V2.1 provides the capability
           of filtering frames to be forwarded by the bridge.  Via a
           programming interface, a user program can determine which frames are
           allowed to pass across the bridge. This feature is particularly
           useful to limit bridge traffic when a relatively slow TP line is
           used between the bridge halves (for example, 9.6 Kbps or 19.2 Kbps).
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.2

           The IBM Token-Ring Network Bridge Program V2.2 allows the use of a
           dial up line between the two halves of a remote bridge, so that the
           cost of a dedicated leased line for occasional traffic need not be
           borne. This also means that the two LANs being interconnected by the
           bridge can be varied according to the connectivity required.
 IBM PC NETWORK BRIDGE PROGRAM.

           A more general LAN segment interconnection solution is offered by
           IBM PC Network Bridge Program.  A bridge running the IBM PC Network
           Bridge Program supports interconnection between any two of the
           following LAN segments:
           o   4 Mbps IBM Token-Ring Network
           o   PC Network (Baseband)
           o   PC Network (Broadband) operating on channel pair T13 - J
           o   PC Network (Broadband) operating on channel pair 2' - O
               (Frequency 2)
           o   PC Network (Broadband) operating on channel pair 3' - P
               (Frequency 3)
           The PC Network segments, operating on different channel pairs, may
           or may not share the same broadband medium.

           In this way, PC Network attached devices may have access to host
           gateway devices attached to token-ring segments of the network.
 8209 LAN BRIDGE

           The IBM 8209 allows either a token-ring to token-ring local bridge
           or a token-ring to be bridged to a LAN segment that is running
           Ethernet Version 2 or IEEE 802.3 MAC protocols.  This dedicated
           machine allows a rich set of inter-connection possibilities between
           IBM and non-IBM equipment, given that many OEM products and
           protocols are supported by Ethernet connectivity.
 IBM Token-Ring Network Bridge Program V2, IBM 8209 LAN Bridge and IBM PC
 Network Bridge Program are all capable of communicating with IBM LAN Manager
 V2.0, and IBM LAN Network Manager, providing consistent network management for
 the entire multi-segment LAN.
 Before looking at the specific IBM bridge product implementations, Figure 97
 under heading "6.6  IBM LAN Bridges" shows the major components and their
 interfaces for a local bridge between two LAN segments.
 +------------------------------------------------------------------------------
 ]
 ]
 ]                        *----------------------*
 ]     LAN Manager <----->]    Bridge Manager    ]<-----> End-User
 ]                        *----------------------*
 ]                           ] Bridge Adapter ]
 ]                           ]    Interface   ]
 ]       *-------------*<--->*----------------*<--->*-------------*
 ]       ] LAN Adapter ]         *--------*         ] LAN Adapter ]
 ]       ] microcode   ]<------->] common ]<------->] microcode   ]
 ]       *-------------*         ] memory ]         *-------------*
 ]        LAN Segment A          *--------*          LAN Segment B
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 97. LAN Bridge Structure
 Similarly, Figure 98 under heading "6.6  IBM LAN Bridges" illustrates the
 major components and their inter-relationship for a remote bridge.
 +------------------------------------------------------------------------------
 ]
 ]
 ]LAN Mgr  <-->*----------------*          *----------------*<--> LAN Mgr
 ]             ] Bridge Manager ]          ] Bridge Manager ]
 ]End-User <-->*----------------*          *----------------*<--> End-User
 ]              ]Bridge Adapter]            ]Bridge Adapter]
 ]              ]  Interface   ]            ]  Interface   ]
 ]*-------*<--->*---------------*          *---------------*<--->*-------*
 ]]  LAN  ]           ]TP Comms.]          ]TP Comms.]           ]  LAN  ]
 ]]Adapter]           ]Adapter  ]          ]Adapter  ]           ]Adapter]
 ]*-------*           ]Interface]          ]Interface]           *-------*
 ]Segment A           *---------*          *---------*           Segment B
 ]                         ]                    ]
 ]                    *---------*          *---------*
 ]                    ]TP Comms.]-----/    ]TP Comms.]
 ]                    ]Adapter  ]    /-----]Adapter  ]
 ]                    *---------* TP line  *---------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 98. Remote Bridge Structure

 6.6.1  IBM Token-Ring Bridges
 The IBM Token-Ring Bridge program versions 1.0 and 1.1 have been superseded by
 IBM Token-Ring Network Bridge Program V2 which is available in three releases.
 IBM Token-Ring Network Bridge Program V2.2 superseded IBM Token-Ring Network
 Bridge Program V2.1, which was withdrawn from marketing in September 1990.
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V1.1
 o   Interconnects 4Mbps ring segments
 o   Implements LAN Reporting Mechanism (LRM). See "6.4 Bridge LAN Management
     Interface."
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.0
 o   Supersedes IBM Token-Ring Network Bridge Program V1.1
 o   Interconnects 4Mbps and 16Mbps token-ring segments
 o   Implements DYNAMIC SINGLE-ROUTE BROADCAST PATH MAINTENANCE

 6.6.1.1.1.1  Single-Route Broadcast Path Maintenance:  The bridge can be
 configured with the configuration utility or by the IBM LAN Manager V2.0 to
 communicate with other active bridges to dynamically maintain the network
 single-route broadcast path.
 A bridge, configured to participate in the dynamic maintenance of the
 network's single-route broadcast path, can be in any of three modes:
 BLOCKING  The bridge does not forward single-route broadcast frames and does
           not participate in the bridge protocols.
 LISTENING The bridge does not forward single-route broadcast frames but
           participates in the bridge protocols.
 FORWARDING
           The bridge forwards single-route broadcast frames and participates
           in the bridge protocols.
 A bridge is in blocking mode during initialization.  Once the bridge has
 opened its adapters and has set the appropriate functional address, it enters
 listening mode.  After participating in the protocols long enough to determine
 if it should forward single-route broadcast frames, the bridge will either
 stay in listening mode or enter forwarding mode.  Bridges participating in the
 protocols monitor the single-route broadcast path with inter-bridge
 communication, using Bridge Protocol Data Units (BPDUs).  All inter-bridge
 communication is sent as logical link control Type 1 (connectionless) data to
 the bridge functional address (X'C00000000100').  The inter-bridge
 communication is periodically initiated by a frame sent from the ROOT bridge.
 This root bridge is automatically selected through processes specified by the
 spanning tree algorithm.
 The bridges will reconfigure the single-route broadcast path to accommodate
 network changes caused by a new bridge being activated or an active bridge
 being shutdown.
 It is important to notice that single-route broadcast path maintenance does
 not affect the way in which a bridge processes all-routes broadcast or
 non-broadcast frames.
 o   Sends management information to IBM LAN Manager V2.
     -   Soft error reports and beaconing notification
     -   Bridge status and performance data
     -   Ring configuration reports.
 IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.1
 o   Supersedes IBM Token-Ring Network Bridge Program V2.0
 o   Able to act as a remote bridge

     IBM Token-Ring Network Bridge Program V2.1 can be configured as a REMOTE
     BRIDGE, also called SPLIT BRIDGE.

     A remote bridge consists of two bridge halves connected by a TP line.
     Each bridge half requires a token-ring network adapter attached to a LAN
     segment and a communications adapter.  In this case, frames are
     transferred between the two interconnected IBM token-ring network segments
     via a leased teleprocessing (TP) line operating at speeds ranging from 9.6
     Kbps to 1.344 Mbps.

     Configuration information is passed across the communications link
     directly during bridge initialization. Both bridge halves verify that the
     common information matches (for instance bridge number and ring segment
     number).  In addition, when any of the operational bridge parameters is
     changed by the IBM LAN Manager V2.0 or IBM LAN Network Manager, both
     bridge halves will be updated.

     Bridge performance reporting has also been enhanced to reflect split
     bridge specific information. As mentioned earlier, a special FRAME NOT
     FORWARDED, FILTERED counter is maintained to report the result of frame
     filtering by a user exit.  In addition, another counter is used to
     accumulate the number of frames which are not forwarded because a cyclic
     redundancy check (CRC) error is detected on the TP communications link.

     Particularly when the TP link is operated at a relatively low transmission
     speed, token-ring adapter buffering capacity may sometimes be insufficient
     to store incoming frames from the ring segment before they can be
     transmitted to the other bridge halve.  Therefore, with a split bridge,
     the FRAME NOT RECEIVED (ADAPTER CONGESTED) counter may reach its threshold
     much faster than it would for the same segments and same traffic in a
     standard bridge configuration.

     The halves of the remote bridge can be attached to the telecommunication
     network in one of the following ways:
     -   Via synchronous modems, providing the following interfaces at the
         indicated speeds:
         --  EIA RS-232C/CCITT V.24 at 9.6 Kbps to 19.2 Kbps.
         --  CCITT V.35 at 9.6 Kbps to 1.344 Mbps.
         --  X.21 bis/CCITT V.24 at 9.6 Kbps to 19.2 Kbps.
         --  X.21 bis/CCITT V.35 at 9.6 Kbps to 1.344 Mbps.
         --  X.21 (leased only) at 9.6 Kbps to 64 Kbps.
     -   Via a multiplexor, such as the Integrated Digital Network Exchange
         (IDNX) Models 20, 40 and 70 through:
         --  The USD or HSD communications adapter using CCITT V.35 at 9.6 Kbps
             to 1.344 Mbps.
         --  The QSD communications adapter using EIA RS-232C/CCITT V.24 at 9.6
             Kbps to 19.2 Kbps.
         --  The QSD communications adapter using CCITT V.35 at 9.6 Kbps to 56
             Kbps.

     An additional bridge parameter, COMMUNICATIONS ADAPTER ELECTRICAL
     INTERFACE, identifies the electrical interface used by the communications
     adapter to attach to the TP link. Valid options are 1 (RS-232), 2 (RS-422)
     and 3 (V.35, default value).

     The IBM Token-Ring Network Bridge Program V2.1 maintains an internal
     protocol over the TP line between the two bridge halves.

     Communications across a remote bridge, operating with a 1.344 Mbps TP
     line, is transparent to applications written to the IEEE 802.2 logical
     link control interface using source routing. However, in general,
     different restrictions apply with respect to line speed, maximum time
     delay, frame size, line error rate and number of active concurrent
     sessions through the bridge.  The common rational behind these different
     restrictions is to avoid end-to-end session time-out due to excessive
     delays experienced while crossing the remote bridge.

 o   Bridge frame filtering capability

     FRAME-FORWARD FILTERING, provides a mechanism to limit the traffic across
     a bridge.  A bridge parameter, FILTERING ENABLED, enables invocation of a
     FILTER USER APPENDAGE during the frame forwarding decision process.  If
     the filter appendage returns a no forward indicator the frame will be
     discarded and a specific counter (frame not forwarded, filtered) is
     incremented.  A FILTER USER APPENDAGE program can be created through a
     programming interface offered with the IBM Token-Ring Network Bridge
     Program V2.1. Three filtering programs are supplied with the product. They
     can be used to filter frames based on:
     -   Protocol, for example: do not pass NETBIOS frames
     -   Destination or source MAC addresses
     -   Number of logical link connections established over the bridge.

 6.6.2  IBM Token-Ring Network Bridge Program Version 2.2
 The IBM Token-Ring Network Bridge Program Version 2.2 enhances the function of
 the IBM Token-Ring Network Bridge program V2.0 and V2.1 in the areas of remote
 bridge support, while maintaining the same bridging and network management
 functions as previous releases of Version 2 of the product.
 For the remote bridge function, supported link speeds and the electrical
 interfaces to the telecommunications link are identical to those supported by
 IBM Token-Ring Bridge Program V2.1.
 The new functions for remote bridge configurations are:
 o   Support for larger frames to cross the bridge
 o   Dial support, enabling the use of a low-speed analogue link using the
     Public Switched Telephone Network (PSTN), between bridge halves.
 o   Provision for better management of the telecommunications link.
 o   Support for the new IBM 7820 Integrated Services Digital Network (ISDN)
     Terminal Adapter, enabling bridge halves to be connected over an ISDN
     network (also supported in IBM Token-Ring Network Bridge Program Version
     2.1).

 6.6.2.1.1  Larger Frame Sizes:  In the IBM Token-Ring Network Bridge Program
 V2.1, the first release of the IBM Token-Ring Bridge program to include a
 "remote bridge" capability, the default value for the maximum frame size
 supported was based on the speed of the link. There were three reasons for
 this:
 1.  Transmitting long frames on slow links takes time, and therefore impacts
     timer values used between communicating stations; for example, the logical
     link control (LLC) acknowledgement timer (T1) may have to be lengthened to
     take account of the increased transmission time.
 2.  Long frames could mean that the bridge becomes congested more easily.
     Since the rate of frame transmission on the link could be much slower than
     the rate of frame arrival from the ring, long queues of frames waiting to
     be transmitted could develop in the bridge. Since applications are only
     able to send a certain number of frames before requiring a response,
     keeping the frames short means that individual stations cannot queue so
     many bytes of data. This in turn means that the bridge should become less
     easily congested, or that more concurrent connections can be efficiently
     supported over the bridge.
 3.  Slower analog links are more prone to suffer errors than the higher-speed
     digital links.  Therefore the likelihood of a long frame on a slow link
     suffering an error is increased. Since the remote bridge does not perform
     any error recovery for link-related errors, recovery has to be done by the
     end stations that are communicating over the bridge. This means that the
     error rate must be kept low enough so that an application is not affected
     by the re-transmission of its frames and the wasted time taken on the
     link.
 Maximum frame size also depended on the amount of storage allocated within the
 bridge machine for the Communication Adapter Transmit Buffer Size.  In the
 original release of IBM Token-Ring Bridge Program 2.1, this was limited to
 64Kb. This meant that if the allowable frame size was large, the number of
 buffers available was restricted.  A Program Temporary Fix (PTF) UR27835 was
 made available to increase bridge throughput for small frame sizes.  With the
 PTF applied, high-speed links can now be driven at 85 percent for longer
 periods of time.
 NOTE:   It should be pointed out that the default frame sizes were only
 RECOMMENDATIONS. A token-ring administrator was able to override the defaults
 when configuring the bridge program.
 The largest frame size allowed when using the remote bridging capability of
 IBM Token-Ring Bridge Program V2.1 was 2052 bytes. This value was recommended
 when the link speed was greater than 56Kbps.
 With IBM Token-Ring Bridge Program V2.2, the defaults are still related to
 link speed, but the absolute maximum sizes have been increased to 8144 bytes
 (16/16Mbps bridge only) or 4472 bytes (4/4Mbps or 4/16Mbps).
 The maximum recommended (defaulted) frame sizes are detailed in Figure 99
 under heading "6.6.2.1.1  Larger Frame Sizes".

 +----------------------------------------------------------------------------+
 ] Figure 99. Recommended Maximum Frame Sizes                                 ]
 +--------------------------------------+-------------------------------------+
 ] TP Link Speed (Kbps)                 ] Frame size                          ]
 +--------------------------------------+-------------------------------------+
 ] 9.6 to < 38.4                        ] 516                                 ]
 +--------------------------------------+-------------------------------------+
 ] 38.4 to < 56                         ] 1500                                ]
 +--------------------------------------+-------------------------------------+
 ] 56 to < 1.344Mbs                     ] 2052                                ]
 +--------------------------------------+-------------------------------------+
 ] 1.344Mbps                            ] 4472                                ]
 +--------------------------------------+-------------------------------------+
 Use of a frame size as large as 8144 is only possible when both sides of the
 remote bridge have either the IBM Token-Ring 16/4 Adapter or the IBM
 Token-Ring 16/4 Adapter/A installed with the full 64K of on-card RAM utilized,
 both rings are operating at 16Mbps, and the TP link speed is 1.344Mbps.  If a
 high rate of errors is detected when using this value, the maximum frame size
 should be reduced to 4472.

 6.6.2.1.2  Cascading Remote Bridges:  Cascading of remote bridges is not
 restricted, however several factors must be considered when implementing this
 configuration.  The TP link speed is critical in determining whether
 applications will work across cascaded remote bridges. The link protocol used
 between the end stations, for example LLC Type 2, may have timer values which
 must be met for the logical link to be maintained. In addition, the
 application itself may have timing constraints. In a cascaded configuration,
 and particularly at slower link speeds, these timing constraints may not be
 met. It is the customer's responsibility to determine whether specific
 applications will work in this configuration.
 NOTE:  As with local bridges, IBM Token-Ring Architecture restricts a frame
 from crossing more than seven bridges in its path from end station to end
 station.

 6.6.2.1.3  Dial Support:  Many customers need only occasional access to remote
 LANs. For instance, a small stand-alone LAN, situated in a travel agency or a
 banking branch, may provide all the local day-to-day services required.
 Sometimes, perhaps for the purpose of software management or server
 administration, there may be a need for skilled personnel to access the LAN
 from a central site, or, for the branch office to transfer information to
 another branch. A remote LAN bridge enables that function, but the cost of the
 dedicated lines, used only occasionally, may make the approach expensive.  By
 using a switched telephone line between the bridge halves, connection can be
 established when required, and also between different locations depending on
 instantaneous need.
 The IBM Token-Ring Bridge Version 2.2 can use a dial-up connection between the
 two halves of a remote bridge. This support is provided by:
 o   New configuration parameters in the bridge halves
 o   Support of a V.25 bis modem, typically operating at 9.6Kbps, such as the
     IBM 7855-10 V.32 modem
 o   Provision of an application program that will request the "local" half of
     a remote bridge to make a call.
 The scenario is illustrated in Figure 100 under heading "6.6.2.1.3  Dial
 Support".
 -------------------------------------------------------------------------------

        *----*   *---*                         *----* *---* *---*
        ]Srvr]   ]   ]                         ]Srvr] ]   ] ]   ]
        *----*   *---*                         *----* *---* *---*
     *---------------*                        *------------------*
     ] Token-Ring "A"]                        ]  Token-Ring "B"  ]
     *---------------*                        *------------------*
              *---*                               *---*
              ]   ]Bridge Half         Bridge Half]   ]
              *---*                               *---*
             *-----*                             *-----*
             ]Modem]                             ]Modem]
             *-----*                             *-----*
                &TELEPHONE.                                  &TELEPHONE.
                              *-----*
                              ]Modem]&TELEPHONE.
                              *-----*
                               *---*
                               ]   ]Bridge Half
                               *---*
 *-------------*  *-------------------------------*
 ]     LAN     ]  ]                               ]
 ]Administrator]--]    Head Office Token-Ring     ]
 *-------------*  ]                               ]
                  *-------------------------------*
 -------------------------------------------------------------------------------
 Figure 100. Remote Bridge with Dial Support
 The figure shows two small "branch-office" token-rings each with its own
 server. The LAN administrator, using IBM Token-Ring Bridge Program V2.2 can
 dial up either branch when required. Also Branch "A" is able to connect to
 Branch "B" when they need to exchange data. The cost of the connection is
 related to the length of the call, and the connectivity is versatile.
 Dial support offers:
 o   Ability for a bridge to initiate outgoing calls, accept incoming, or both.
 o   Password protection, so that unauthorized users cannot initiate calls.
 o   Call setup using an IBM-provided application shipped with the product.
     Users are also given information allowing them to write their own
     application. This could allow the user a menu selection of possible
     locations.
 o   Alternative ability to use a number pre-stored in the modem.
 o   Call progress signals from the bridge to the application program
     indicating the status of the connection attempt.
 o   Call takedown when:
     -   Requested by the operator
     -   No frames have been forwarded over the bridge for a user-specifiable
         time.
     -   Certain line error conditions occur.

     The bridge is fully configurable for a wide range of timer values that may
     be stipulated by country PTT regulations when operating V.25 bis modems on
     switched circuits.

 6.6.2.1.4  Telecommunications Link Management:  Improved support for managing
 a remote bridge is provided by the following:
 o   When displaying ring status information, both halves will display both
     rings' status.
 o   When configuration information is displayed, both halves will display both
     halves' configuration information.
 o   A new alert is provided to report the status of the link to the LAN
     Network Manager Version 1.0, if the LAN Network Manager is linked to the
     bridge.
 Support is provided by the IBM LAN Network Manager Version 1.0 or later.

 6.6.2.1.5  IBM 7820 ISDN Terminal Adapter Support:  The IBM 7820 is a terminal
 adapter that allows devices with the V.24, V.35 or X.21 interfaces to access
 basic rate ISDN links. This means that the two halves of a remote bridge may
 be connected over an ISDN network.

 6.6.2.1.6  Hardware/Software Requirements:  HARDWARE REQUIREMENTS:
 o   Computer
     -   IBM PC/AT
     -   IBM 7531, 7532, 7541, 7542, 7552, 7561 and 7562 Industrial Computers
     -   IBM Personal System/2 Model 30 or above.
 o   Minimum memory requirement is 512Kb.
 o   At least one 720Kb or 1.2Mb disk drive
 o   Token-ring adapters can be any of those supported by IBM Token-Ring Bridge
     Program Version 2.1 or either of the IBM Token-Ring Network 16/4 Adapters.
 o   When running in the remote bridge configuration, two matching RTIC cards
     are needed. Either:
     -   IBM Real-time Interface Co-processor Card with 512Kb storage (Family
         1)
     -   IBM X.25 Interface Co-Processor/2 (Family 2)
     together with the cable features to support the required electrical
     interface - V.24, V.35, or X.21.
 o   If using the Dial support, a V.25 bis modem, such as the IBM 7855-10 V.32
     modems
 o   If attaching to an ISDN Network, an IBM 7820 ISDN Terminal Adapter.
 SOFTWARE REQUIREMENTS:  For each half of a remote bridge configuration, the
 following are required:
 o   IBM Token-Ring Network Bridge Program V2.2
 o   IBM PC DOS 3.3 or above
 o   IBM Real-time Interface Co-processor Support for DOS, Version 1 or higher.

 6.6.3  IBM PC Network Bridge Program
 The IBM PC Network Bridge Program provides MAC level interconnection between
 the following LAN segments:
 o   Two IBM Token-Ring Network segments operating at 4 or 16 Mbps.
 o   Two IBM PC Network broadband segments.
 o   An IBM Token-Ring Network segment operating at 4 Mbps or 16 Mbps and an
     IBM PC Network broadband segment.
 Each individual IBM PC Network (Broadband) segment can operate at any of the
 three supported frequency channel pairs. If PC Network (Broadband) segments
 share the same broadband medium (at different frequencies), the IBM PC Network
 Bridge Program product may be used to bridge between the two frequencies. In
 this case, both adapters would be attached to the same piece of coaxial cable.
 Although the IBM PC Network Bridge Program may interconnect two token-ring
 network segments, its primary purpose is to integrate PC Network segments into
 a larger (token-ring based) LAN environment, extending the connectivity
 options for PC Network devices and allowing improved integration of LAN
 management.
 For any type of LAN interconnection, the IBM PC Network Bridge Program uses
 the concepts of source routing.  The bridge function is transparent to
 applications written to the IEEE 802.2 logical link control interface using
 source routing, whether the MAC protocol at either side of the bridge is
 identical or dissimilar. The expected bridge throughput, however, depends on
 the type of interconnected MAC segments.
 The IBM PC Network Bridge Program includes all the network management support
 provided by IBM Token-Ring Network Bridge Program V2 and also supports
 forwarding of network management data from PC Network segments.  Like IBM
 Token-Ring Network Bridge Program V2, IBM PC Network Bridge Program interfaces
 with up to four LAN Managers executing IBM LAN Manager V2.0 or IBM LAN Network
 Manager.
 The following IBM Token-Ring Network management information is sent to IBM LAN
 Manager V2.0 or IBM LAN Network Manager:
 o   Soft error reports and beaconing notification
 o   Bridge status and performance data
 o   Ring configuration reports
 o   Path trace reports.
 The following PC Network (Broadband) management information is sent to IBM LAN
 Manager V2.0 or IBM LAN Network Manager:
 o   Continuous carrier and no carrier notifications
 o   Bridge status and performance data
 o   Ring configuration reports
 o   Path trace reports
 o   Topology reports (although the sequence between stations on a CSMA/CD LAN
     segment is irrelevant).
 The IBM PC Network Bridge Program also supports dynamic single-route broadcast
 path configuration and maintenance.
 Figure 101 under heading "6.6.3  IBM PC Network Bridge Program" shows the
 general structure of IBM PC Network Bridge Program when connecting a PC
 Network (Broadband) segment and an IBM Token-Ring Network segment.  The IBM PC
 Network Bridge Program includes adapter handlers for both PC Network and the
 IBM Token-Ring Network, as well as logical link control and bridge protocol
 software to support PC Network adapters.
 +------------------------------------------------------------------------------
 ]
 ]
 ] *---------------------------------------------------------------------*
 ] ] IBM PC Network Bridge Program                                       ]
 ] ]       *-----------------------------------------*                   ]
 ] ]    *--]      LAN reporting mechanism (LRM)      ]--*                ]
 ] ]    ]  *-----------------------------------------*  ]                ]
 ] ]    ]        ]     ]     ]     ]     ]     ]        ]                ]
 ] ]    ]      *---* *---* *---* *---* *---* *---*      ]                ]
 ] ]    ]      ]LEM] ]LPS] ]LBS] ]CRS] ]RPS] ]REM]      ]                ]
 ] ]    ]      *---* *---* *---* *---* *---* *---*      ]                ]
 ] ]    ]        ]     ]    ] ]    ]     ]     ]        ]                ]
 ] ]    ]       *-------------------------------*       ]                ]
 ] ]    ]       ]  CSMA/CD   ]    MAC Frame     ]       ]                ]
 ] ]    ]     *-]  Router    ]    Router        ]-*     ]                ]
 ] ]    ]     ] *-------------------------------* ]     ]                ]
 ] ] ...].....]...................................].....]............... ]
 ] ] *-----------------------------------------------------*  External   ]
 ] ] ]   PC Network    ]  Bridge Frame   ] Token-Ring N/W  ]  Interface  ]
 ] ] ] Adapter Handler ]  Forward Logic  ] Adapter Handler ]  (Int X'5C')]
 ] ] ]-----------------+-----------------------------------*             ]
 ] ] ]  LLC  ] Direct  ] Bridge ]    ]            ]     ]                ]
 ] ] ]--------------------------]    ]            ]     ]                ]
 ] ] ] Protocol Interface Driver]    ]            ]     ]                ]
 ] ] *--------------------------*    ]            ]     ]     Hardware   ]
 ] ]          ]                      ]            ]     ]     Interface  ]
 ] *---------------------------------------------------------------------*
 ]            ]                      ]            ]     ]
 ] *---------------------------------------------------------------------*
 ] ] Adapter  ]                      ]            ]     ]                ]
 ] ] Cards    ]                    *-----------------------*             ]
 ] ]          ]                    ] Bridge ] Direct ] LLC ]             ]
 ] ] *-----------------------*     ]-----------------------]             ]
 ] ] ] Medium Access Control ]     ] Medium Access Control ]             ]
 ] ] ]-----------------------]     ]-----------------------]             ]
 ] ] ]  Physical Transport   ]     ]  Physical Transport   ]             ]
 ] ] *-----------------------*     *-----------------------*             ]
 ] ]    PC Network Adapter         Token-Ring Network Adapter            ]
 ] ]       LAN segment A                 LAN segment B                   ]
 ] *---------------------------------------------------------------------*
 ]
 +------------------------------------------------------------------------------
 Figure 101. IBM PC Network Bridge Program - General Bridge Structure
 The IBM PC Network Bridge Program end-user (19 under heading "6.6.3  IBM PC
 Network Bridge Program") server functions, as opposed to internal system
 server functions, are referenced explicitly in Figure 102 under heading "6.6.3
 IBM PC Network Bridge Program".
 ]
 ]
 ]*-------------------------------------------------------------*
 ]] IBM PC Network Bridge SERVER      ] Token-Ring ] PC Network ]
 ]]                                   ] N/W Segment]  Segment   ]
 ]]-----------------------------------+------------+------------]
 ]] LAN reporting mechanism (LRM)     ]    Yes     ]    Yes     ]
 ]]-----------------------------------+------------+------------]
 ]] Ring Error Monitor (REM)          ]    Yes     ]     No     ]
 ]]-----------------------------------+------------+------------]
 ]] LAN Error Monitor (LEM)           ]     No     ]    Yes     ]
 ]]-----------------------------------+------------+------------]
 ]] Ring Parameter Server (RPS)       ]    Yes     ]     No     ]
 ]]-----------------------------------+------------+------------]
 ]] LAN Parameter Server (LPS)        ]     No     ]    Yes     ]
 ]]-----------------------------------+------------+------------]
 ]] Configuration Report Server (CRS) ]    Yes     ]    n/a     ]
 ]]-----------------------------------+------------+------------]
 ]] LAN Bridge Server (LBS)           ]    Yes     ]    Yes     ]
 ]*-------------------------------------------------------------*
 ]
 ]
 +------------------------------------------------------------------------------
 Figure 102. IBM PC Network Bridge Program End-User Servers

 PC Network stations use LLC protocols for network control functions.
 Therefore they can communicate directly with a LAN Manager, and PC Network
 segments do not need a CRS server function provided by the bridge.
 Bridge processing by the LAN Bridge Server function includes also SINGLE-ROUTE
 BROADCAST PATH MAINTENANCE.  If this spanning tree algorithm is desired, all
 bridges in the multi-segment LAN must be configured to participate in the
 dynamic maintenance protocols.

 6.6.3.1.1.1  Hardware and Software Requirements:  IBM PC Network Bridge
 Program requires a dedicated IBM Personal System/2 Model 50, 60, 70 or 80. It
 requires 384 Kbytes of memory and a 720 Kbyte or 1.2 Mbyte 3.5 inch diskette
 drive.
 Local area network adapters supported are shown in Figure 103 under heading
 "6.6.3.1.1.1  Hardware and Software Requirements".

 *------------------------------------------------------------*
 ] AFE                                       ]   P/N   /  FC  ]
 ]-------------------------------------------+----------------]
 ] IBM Token-Ring Network Adapter /A         ] 69X8138 / 4790 ]
 ] IBM Token-Ring Network 16/4 Adapter/A     ] 16F1133 / 1133 ]
 ] IBM PC Network Adapter II/A               ] 25F8278 /      ]
 ] IBM PC Network Adapter II/A - Frequency 2 ] 25F8281 /      ]
 ] IBM PC Network Adapter II/A - Frequency 3 ] 25F8284 /      ]
 ]-------------------------------------------+----------------]
 ] (EMEA)                                    ]   P/N   /  FC  ]
 ]-------------------------------------------+----------------]
 ] IBM Token-Ring Network Adapter /A         ] 69X8138 / 4790 ]
 ] IBM Token-Ring Network 16/4 Adapter/A     ] 16F1133 / 1133 ]
 ] IBM PC Network Adapter II/A               ] 25F8280 /      ]
 ] IBM PC Network Adapter II/A - Frequency 2 ] 25F8283 /      ]
 ] IBM PC Network Adapter II/A - Frequency 3 ] 25F8286 /      ]
 *------------------------------------------------------------*

 Figure 103. IBM PC Network Bridge Program - Bridge Supported Adapters
 IBM PC Network Bridge Program's only software prerequisite is IBM PC/DOS 3.3
 or 4.0 Devices attached to a broadband PC Network segment being bridged by the
 IBM PC Network Bridge Program require IBM Local Area Network Support Program
 Version 1.0 with PTF UR22583 or Version 1.1.

 6.7  IBM 8209 LAN Bridge
 The IBM 8209 LAN bridge is a stand-alone bridge product that may have one of
 two configurations. Depending on the product feature code ordered, it may act
 as a:
 1.  Token-Ring to Token-Ring bridge, when ordered with the IBM 8209 Token-Ring
     attachment module
 2.  Token-Ring to Ethernet/IEEE802.3 bridge, when ordered with the IBM 8209
     Ethernet or Enhanced Ethernet Attachment Feature.

     The additional function of the Enhanced Ethernet Attachment feature is
     described in "6.7.9 Enhanced Ethernet Attachment Feature."
 As originally announced, the 8209 bridged an Ethernet/IEEE802.3 LAN to a
 token-ring. The token-ring/token-ring capability is new.  In either
 configuration, one side of the bridge always connects to a token-ring.
 The following pages describe the function and operation of both
 configurations. As a token-ring to Ethernet bridge, the function is much more
 complex, so the description is extended. A bridge between token-ring and
 token-ring has already been described in relation to the IBM Token-Ring Bridge
 Program, so the highlights and differences between the 8209 and the Bridge
 Program will be all that is discussed here.

 6.7.1  Token-Ring to Token-Ring
 Configured in this way, the 8209 bridge:
 o   Can act only as a LOCAL bridge between two token-rings, with each ring
     operating at either 4 or 16Mbps
 o   Is a stand-alone, rack mountable machine, requiring no keyboard or display
 o   Offers filtering and similar network management capabilities to the IBM
     Token-Ring Bridge Program Version 2.2
 o   Provides PLUG AND PLAY customer installation
 o   Is supported for network management by the IBM LAN Manager V2.0 or above
 o   Is provided with a utility program that may be used to configure the
     bridge and retrieve bridge profile if an IBM LAN Manager is not present on
     the LAN.
 Before the announcement of this product, token-ring bridges were provided by
 software and PC or PS/2 hardware. This meant that the PCs or PS/2s required
 keyboard and display components that were for the most part redundant. A
 standalone bridge enables customers to have a black-box bridge function, and
 allows them to re-use the the former bridge workstation as an end-user
 machine.
 The 8209 token-ring bridge implements all the network management functions
 associated with the local IBM Token-Ring Network Bridge Program Version 2.2.
 These include the functional addresses, (LAN Bridge Server, Ring Error Monitor
 etc.)  as well as the capability for single-route broadcast path maintenance.
 A utility program, supplied with the token-ring attachment module allows the
 user to set up filters to control the traffic forwarded between the rings, as
 well as perform the bridge definition functions.  The utility can be used to
 set up the token-ring segment numbers, the bridge number and all the other
 parameters usually defined within the IBM Token-Ring Bridge Program. Filtering
 capabilities allow an address filter, as well as the setting up of customer
 defined filters.
 The 8209 token-ring to token-ring bridge should offer a performance
 enhancement over the IBM Token-Ring Bridge Program implementation bridge
 solution.

 6.7.2  Token-Ring to Ethernet/IEEE 802.3
 The IBM 8209 can provide an Ethernet/IEEE 802.3 to token-ring bridging
 function when ordered with the Ethernet or Enhanced Ethernet Attachment
 Feature.  From discussions in previous chapters, in particular in "2.2 LAN
 Medium Access Protocols" and "3.0 LAN Architectures and Standards," there are
 many differences between the two types of LAN. They use different access
 control mechanisms, CSMA/CD or token-passing, and even the name Ethernet is
 commonly used to describe three different LAN types:  Ethernet Version 1 (V1)
 Ethernet Version 2 (V2) and IEEE 802.3.
 Ethernet V1, now obsolete, differs from V2 at the physical layer, and Ethernet
 V2, although compatible physically with IEEE 802.3, uses different frame
 formats, such that stations conforming to one type can not correctly interpret
 frames sent by the other.  Token-ring frames are different from both.
 Note that Ethernet Version 1 is not supported by the 8209.
 Ethernet/IEEE 802.3 LANs have standardized on the transparent bridging
 approach to interconnecting segments, using the spanning tree algorithm to
 create a single network path while token-ring has opted for the source routing
 architecture.
 All this means that a protocol transparent, or MAC layer, bridge that
 interconnects a token-ring segment with an Ethernet/IEEE 802.3 segment must do
 more than receive a frame from one LAN segment, and transmit it on the other.
 The IBM 8209 Token-Ring/Ethernet bridge is designed to perform the necessary
 conversion of frames.  The bridge must:
 o   Be seen by the token-ring segment as a source routing bridge
 o   Be seen by the Ethernet/IEEE 802.3 segment as a transparent bridge
 o   Support the IEEE spanning tree protocol
 o   Be able to interpret the frames of Ethernet Version 2 and map them into
     token-ring frames (and vice versa)
 o   Be able to interpret the frames of the IEEE 802.3 protocol and map them
     into token-ring frames (and vice versa).
 The IBM 8209 is used to connect multiple LAN types into a single logical
 network, as can be seen in Figure 104 under heading "6.7.2  Token-Ring to
 Ethernet/IEEE 802.3".
 -------------------------------------------------------------------------------

           *---*   *---*  *---*  *---*         *------*
           ]W/S]   ]W/S]  ]W/S]  ]W/S]         ]Server]
           *---*   *---*  *---*  *---*         *------*
      -------------------------------------------------
               ]    Ethernet V2           ]
               ]                       *----*  *-------*
     ]         ]                *---*  ]8209]  ]Gateway]--/
    E]       *---*E/net to      ]W/S]  *----*  *-------* /-----
    t]-------]   ]E/net Bridge  *---*     ]       ]
    h]       *---*             *---------------------*
    e]                         ]      Token-Ring     ]
    r]  *---*                  *---------------------*
    n]--]W/S]                     ]
    e]  *---*                  *-----*Token-Ring to
    t]                         ]8209 ]Token-Ring Feature
     ]                         *-----*
    V]  *--*                      ]
    2]  ]8 ]    *----------------------*
     ]--]2 ]----]     Token-Ring       ]
     ]  ]0 ]    *----------------------*
     ]  ]9 ]                      ]
        *--*                   *-----*Token-Ring to
                               ]8209 ]Ethernet Feature
                               *-----*
                                  ]
            ------------------------------------------
                 ]       ]       ]       ] IEEE 802.3
               *---*   *---*   *---*   *---*
               ]W/S]   ]W/S]   ]W/S]   ]W/S]
               *---*   *---*   *---*   *---*

   *---*
   ]W/S] = Workstation
   *---*
 -------------------------------------------------------------------------------
 Figure 104. Connecting Multiple LAN Types using the 8209
 In this example, multiple 8209s have been used to connect token-ring attached
 workstations to Ethernet V2 and IEEE 802.3 LANs, such that, given compatible
 higher-layer protocols, workstations can communicate with each other, with the
 server and the communication gateway. This extends the capabilities of both
 sets of stations. It also means that bringing new LAN technology into an
 established environment does not isolate the old and the new.  Token-rings may
 be installed alongside existing Ethernets, perhaps offering advantages in new
 application areas, or token-rings can be used as backbones, connecting
 multiple Ethernets together. The advantages of a token-ring as a backbone are
 great. As discussed in "2.2 LAN Medium Access Protocols" , token-ring
 architecture is capable of providing high data throughput under heavy load; a
 characteristic that is valuable in a backbone LAN.
 The IBM 8209 also lets an Ethernet backbone be used for carrying token-ring
 traffic, though this configuration would mean that frames between token-rings
 stations would be limited to lengths of less than 1500 bytes, the maximum
 allowed on an Ethernet. This may be restricting for the applications, given
 that token-rings can carry much larger frames.
 As well as providing the customer with a homogeneous LAN "cloud", the IBM 8209
 can also take advantage of the management architecture built into the IEEE
 802.5 token-ring. This means that by implementing the functional richness of
 the token-ring, and within the constraints of current Ethernet/IEEE 802.3
 management, the LAN can be managed in its entirety.

 6.7.3  General Description
 The 8209 provides two LAN connections; one for token-ring and one for
 Ethernet/IEEE 802.3. The token-ring port can run at either 4Mbps or 16Mbps.
 The Ethernet port attaches by an Attachment Unit Interface (AUI), allowing the
 8209 to be installed up to 50 meters from the transceiver tap on the coaxial
 cable used as the Ethernet bus.
 When ordered with the Ethernet attachment module, the IBM 8209 is shipped with
 a utility program, suitable for running on a token-ring attached station. This
 station may run either the OS/2 Extended Edition operating system, or PC/DOS
 with the IBM LAN Support Program Version 1.  The function of the utility
 program will be described in "6.7.6 The Utility Program."

 6.7.4  8209 Operation
 Since Ethernet V2 and IEEE 802.3 are compatible at the physical layer, some
 stations on a CSMA/CD segment may be using Ethernet frames while others use
 IEEE 802.3. The different stations cannot communicate with each other, but
 they can share the same physical medium.  The 8209 can be set to recognize
 only Ethernet V2 frames, only IEEE 802.3 frames, or automatically detect which
 station is using which type of frame. This MODE SETTING  depends on the
 setting of the configuration switches. The modes are further described in
 "6.7.5 Frame Conversion"; the switches in "6.7.7 Configuration Switches."
 The 8209 maintains two databases internally; one for stations attached to the
 Ethernet/IEEE 802.3 port, the other for token ring stations that have sent
 frames to Ethernet stations.  Entries in the Ethernet/IEEE 802.3 database may
 be predefined (static), or dynamically created by the 8209.  The static
 entries are created by use of the 8209 utility program.  The database for
 token-ring stations contains only dynamically created entries.
 The purpose of these databases is to contain addressing information for both
 sets of stations, the frame formats used by them (Ethernet V2 or IEEE 802.3),
 and source routing information for the token-ring.  When the 8209 is powered
 on and initialized, entries in the static part of the Ethernet/IEEE 802.3
 database are initialized from pre-configured information kept in non-volatile
 RAM.  The 8209 then enters the LEARNING  state and starts to learn the MAC
 addresses of the stations on the Ethernet/IEEE 802.3 segment, as would any
 other transparent bridge.
 Suppose that an IBM 8209 has been installed between a token ring and an
 Ethernet segment. Some stations on the Ethernet segment are using Ethernet V2
 frames, others are using IEEE 802.3. The 8209 has been setup to automatically
 determine which stations are using Ethernet or IEEE 802.3 frame structures.
 The situation is depicted pictorially in Figure 105 under heading "6.7.4  8209
 Operation".
 -------------------------------------------------------------------------------

  *----------*   *----------*   *----------*  *----------*  *----------*
  ]Mac=11111 ]   ]Mac=22222 ]   ]Mac=33333 ]  ]Mac=44444 ]  ]Mac=55555 ]
  ]Frme=802.3]   ]Frme=E/net]   ]Frme=802.3]  ]Frme=E/net]  ]Frme=E/net]
  *----------*   *----------*   *----------*  *----------*  *----------*
       ]              ]              ]             ]             ]
   --------------------------------------------------------------------
              ]
          *------*            Static Dbase.          Dynamic Dbase.
          ] 8209 ]            Mac   Frme             Mac   Frme
          *------*           *-----------------*    *-----------------*
              ]              ]11111 802.3      ]    ]22222 E/net      ]
   *-----------------*       ]55555 E/net      ]    ]33333 802.3      ]
   ]                 ]       ]                 ]    ]44444 E/net      ]
   ]  Token-Ring     ]       ]                 ]    ]                 ]
   ]                 ]       *-----------------*    *-----------------*
   *-----------------*            8209 Ethernet/IEEE 802.3 databases
          ]
          ]
     *----------*              Mac       Route
     ]Mac=66666 ]            *-----------------*
     ]          ]            ]                 ]
     *----------*            ]                 ]
                             ]                 ]
                             ]                 ]
                             *-----------------*
                               8209 Token-Ring
                              database (dynamic)
 -------------------------------------------------------------------------------
 Figure 105. 8209 Databases - Learning
 The Ethernet/IEEE 802.3 static database has been initialized from the
 predefined entries. As these entries are kept in non-volatile storage, they
 are not lost during an 8209 power outage.  While the 8209 is learning,
 stations on the Ethernet segment will be communicating with each other. The
 8209 observes their frames, analyses them, and can update the dynamic database
 with the stations' MAC addresses and the frame format.  No entries are made in
 the token-ring database.
 After a predetermined time, and if the spanning tree algorithm allows, the
 8209 enters the FORWARDING  state.  The 8209 keeps listening to the frames on
 the Ethernet segment. Any frame that has a source address that is not in the
 database will have an entry made. Thus, the 8209 continues to learn.
 Now assume that the token-ring station with a MAC address 66666 wants to
 communicate with the Ethernet station, address 22222.  Station 66666 will send
 out a frame, addressed to 22222, as a single route broadcast.  This frame will
 be copied by the IBM 8209, which will search its databases for an entry
 corresponding to the destination MAC address 22222. Since the address and
 protocol is known in the dynamic portion of the Ethernet/IEEE 802.3 database,
 it will forward the frame in the correct format.  The token-ring database will
 be updated with the token-ring station's MAC address and any source routing
 information.  The IBM 8209 has a BRIDGE NUMBER , like any other token-ring
 bridge, and the Ethernet is given an "emulated" SEGMENT OR "RING" number.
 These values have been added to the diagram below, and the databases now
 appear as in Figure 106 under heading "6.7.4  8209 Operation"
 -------------------------------------------------------------------------------

  *----------*   *----------*   *----------*  *----------*  *----------*
  ]Mac=11111 ]   ]Mac=22222 ]   ]Mac=33333 ]  ]Mac=44444 ]  ]Mac=55555 ]
  ]Pcol=802.3]   ]Pcol=E/net]   ]Pcol=802.3]  ]Pcol=E/net]  ]Pcol=E/net]
  *----------*   *----------*   *----------*  *----------*  *----------*
       ]              ]              ]             ]             ]
   --------------------------------------------------------------------
   Segment=FF0]
          *------*            Static Dbase.          Dynamic Dbase.
  Bridge#1] 8209 ]            Mac   Pcol             Mac   Pcol
          *------*           *-----------------*    *-----------------*
   Ring=001   ]              ]11111 802.3      ]    ]22222 E/net      ]
   *-----------------*       ]55555 E/net      ]    ]33333 802.3      ]
   ]                 ]       ]                 ]    ]44444 E/net      ]
   ]  Token-Ring     ]       ]                 ]    ]                 ]
   ]                 ]       *-----------------*    *-----------------*
   *-----------------*            8209 Ethernet/IEEE 802.3 databases
          ]
          ]
     *----------*              Mac       Route
     ]Mac=66666 ]            *-----------------*
     ]          ]            ]666666  001,1,FF0]
     *----------*            ]                 ]
                             ]                 ]
                             ]                 ]
                             *-----------------*
                               8209 Token-Ring
                              database (dynamic)
 -------------------------------------------------------------------------------
 Figure 106. 8209 Databases - Forwarding
 When station 22222 returns a frame, the IBM 8209 is able to convert it from
 Ethernet V2 format to token-ring format, adding the routing information,
 extracted from the token-ring database.
 For communication that originates on the Ethernet segment, the 8209 will
 transmit the frame on its token-ring port after reformatting, provided that
 the destination address does not exist in either of the Ethernet/IEEE 802.3
 databases.  This is standard transparent bridging technique - a transparent
 bridge forwards a frame to its other port(s) if the destination address is
 unknown to it.  The frame will be transmitted on the token-ring as a broadcast
 frame; whether single-route or all-routes depends on the type of frame. Any
 response frame will be used to update the token-ring database with MAC address
 and source routing information, since the destination station is now known to
 be accessible through the token-ring.
 The 8209 implements an AGING TIMER. This controls the length of time that
 information remains in the dynamic databases. If no frames are seen for a
 particular destination within this time, then the entry is deleted. This
 prevents the databases becoming full, which would prevent new partner stations
 communicating across the bridge. If an entry has "aged-out", it must be
 rebuilt, using the same techniques that have been described.

 6.7.5  Frame Conversion
 So far, in reviewing the operation of the IBM 8209, we have stated that there
 is a need for frame conversion between Ethernet/IEEE 802.3 LAN segments and
 token-ring LAN segments, but we have not defined why this should be the case,
 or what is required to be done. This section will show why this is necessary
 and how it is done.  Before continuing, the reader may want to refer to "3.2.2
 Logical Link Control Sublayer."  It should be remembered that:
 o   IEEE 802.5 Token-Rings use the IEEE 802.2 specification for logical link
     control. 802.2 provides for both connectionless, TYPE 1 SERVICE , and
     connection-oriented TYPE 2 SERVICE protocols.
 o   IEEE 802.3 CSMA/CD LANs also specify the use of IEEE 802.2 to provide the
     logical link control, and mostly run connectionless.
 o   Ethernet V2 networks do not use logical link control. However, it can be
     simulated by using additional software; for example, OS/2 EE 1.2
     ETHERAND(20)

 ---Footnote---
 (20) ETHERAND is a registered trademark of the IBM Corporation
 --------------

     or the LAN Support Program V1.2.  See "5.6.5 IBM LAN Support Program
     Version 1.2." This implementation is known as LLC-ON-ETHERNET.
 This means that:
 o   Conversion from IEEE 802.3 to IEEE 802.5 is only done to map the frame
     format - the 802.2 Protocol Data Unit (PDU) remains in both networks.
 o   Conversion from Ethernet V2 to 802.5 requires more processing.
 Let us review the individual frame formats. These are shown in Figure 107
 under heading "6.7.5  Frame Conversion"
 -------------------------------------------------------------------------------

 Ethernet V2

     *-----------------------------------*
     ]Preamble]DA]SA]TYPE]Information]FCS]
     *-----------------------------------*

 IEEE 802.3
                           ]-------802.2 LLC PDU---------]

 *---------------------------------------------------------------*
 ]Preamble]SFD]DA]SA]Length]DSAP]SSAP]Control]Information]PAD]FCS]
 *---------------------------------------------------------------*

 IEEE 802.5 Token-Ring

                           ]-------802.2 LLC PDU---------]
         *---------------------------------------------------------*
         ]SD]AC]FC]DA]SA]RI]DSAP]SSAP]Control]Information]FCS]ED]FS]
         *---------------------------------------------------------*

 Key:

 Common                     Ethernet V2           IEEE 802.3

 DA  Destination Address    TYPE Upper layer      SFD Starting Frame
 SA  Source Address              Protocol used        Delimiter
 FCS Frame Check Sequence                         PAD Used to pad info.
                                                      to 46 bytes min.
                                                  Length - of LLC PDU

 IEEE 802.5                 IEEE 802.2 LLC PDU

 SD Starting Delimiter      LLC   Logical Link Control
 AC Access Control          PDU   Protocol Data Unit
 FC Frame Control           DSAP  Destination Service Access Point
 RI Routing Information     SSAP  Source Service Access Point
 ED Ending Delimiter
 FS Frame Status field

 Control
 This field contains the commands, responses, sequence numbers
 and the Poll/Final bit, as used for Asynchronous Balanced Mode Extended.

 Information
 User data

 -------------------------------------------------------------------------------
 Figure 107. LAN Frame Formats
 Apart from the 802.2 PDU present in an IEEE 802.3 frame, the most significant
 difference between an IEEE 802.3 and an Ethernet V2 frame is the Length/Type
 field.

 6.7.5.1.1  Ethernet - Token-Ring

 6.7.5.1.2  Sub-Network Access Protocol:  The Internet community, those people
 responsible for the development of the TCP/IP protocol (see "5.5 TCP/IP") have
 developed a method for transferring data between IEEE networks (802.3, 802.4
 and 802.5) and Ethernet V2 networks. This makes use of the SubNetwork Access
 Protocol (SNAP).  They have specified that for SNAP, the:
 o   The DSAP and the SSAP in the 802.2 header shall be set to x'AA'
 o   The control byte shall be set to x'03'
 o   The first three bytes of the information shall be x'00 00 00' (P_id)
 o   The next two bytes define the protocol being used.
 This now allows a conversion between IEEE 802.5 Token-ring frames, and
 Ethernet V2 frames. This process is summarized in Figure 108 under heading
 "6.7.5.1.2  Sub-Network Access Protocol".
 -------------------------------------------------------------------------------

 Token Ring

                   ]--------SNAP Header--------]
 *-------------------------------------------------------------------*
 ]SD]AC]FC]DA]SA]RI]DSAP]SSAP]Control]P_id]Type]Information]FCS]ED]FS]
 *-------------------------------------------------------------------*
          ]     ]<--------Discard-------->]                ]
          ]Copy ]                         ]      Copy      ]
          V     V                         V                V
 *--------------- - - - - - - - - - - - - ---------------------*
 ]Preamble]DA]SA]                         ]Type]Information]FCS]
 *--------------- - - - - - - - - - - - - ---------------------*

 Ethernet V2

 Ethernet V2

 *--------------- - - - - - - - - - - - - ---------------------*
 ]Preamble]DA]SA]                         ]Type]Information]FCS]
 *--------------- - - - - - - - - - - - - ---------------------*
          ]     ]<--------Insert--------->]                ]
          ]Copy ]                         ]      Copy      ]
          V     V                         V                V
 *-------------------------------------------------------------------*
 ]SD]AC]FC]DA]SA]RI]DSAP]SSAP]Control]P_id]Type]Information]FCS]ED]FS]
 *-------------------------------------------------------------------*

 Token Ring

 -------------------------------------------------------------------------------
 Figure 108. Token-Ring - Ethernet V2 Frame Conversion
 Thus, a protocol that uses SNAP headers can be successfully bridged between a
 token-ring and an Ethernet V2 network. Such a protocol is TCP/IP.

 6.7.5.1.3  LLC-on-Ethernet - Token-Ring:  Logical Link Control protocols can
 be carried in Ethernet frames.  They are used for NETBIOS and SNA by the
 PC-RT, OS/2 Extended Edition 1.2, and the LAN Support Program Version 1.2.
 The information field of the Ethernet frame is formatted as in Figure 109
 under heading "6.7.5.1.3  LLC-on-Ethernet - Token-Ring"
 -------------------------------------------------------------------------------

  Ethernet V2 Information field

     *--------------------------------------------*
     ]Length]PAD]DSAP]SSAP]Control]Information]PAD]
     *--------------------------------------------*
 -------------------------------------------------------------------------------
 Figure 109. LLC-on-Ethernet Information Field Format
 In this frame format, the length value is computed to be from the DSAP value
 to the last byte of the Information field, inclusive. The leading PAD is one
 byte long, and the trailing PAD is only required if it is necessary to
 increase the length to the minimum of 46.
 Conversion from token-ring to Ethernet for the LLC-based protocols is
 performed by the 8209 if the following conditions are met:
 o   LLC-on-Ethernet is enabled in the 8209  (the default is disabled).

     The conversion is done when the 8209 recognizes a value of x'80D5' in the
     Ethernet Type_Field, or a non SNAP-formatted token-ring frame is being
     passed to an Ethernet station.
 o   The DSAP in the token-ring frame must also be a value defined in the 8209
     SAP table. Default values in this table are x'00 04 F4 F0 08 and FC'.
     These values correspond to the null SAP, (00), two SNA SAPs, (04 and 08),
     the LAN management SAP, (F4), the NETBIOS SAP, (F0), and a Discovery SAP
     (FC) used during Remote Program load. The process is shown in Figure 110
     under heading "6.7.5.1.3  LLC-on-Ethernet - Token-Ring".
 -------------------------------------------------------------------------------

 Token-Ring

                                ]--------802.2 LLC PDU--------]
 *----------------------------------------------------------------------*
 ]SD]AC]FC]DA]SA] Routing Info. ]DSAP]SSAP]Control]Information]FCS]ED]FS]
 *----------------------------------------------------------------------*
          ]Copy ]    Discard    ]<-----------Copy------------>]
          ]     ]               ]                             ]
          V     V    Insert     V                             V
          *-----------------------------------------------------------*
          ]DA]SA]type]Length]PAD]DSAP]SSAP]Control]Information]PAD]FCS]
          *-----------------------------------------------------------*
                ]80D5]<------Ethernet Information Field---------->]
 Ethernet V2    ]    ]    See Figure 109 under heading "6.7.5.1.3  LLC-on-Ethern

 Ethernet V2

                                ]--------802.2 LLC PDU--------]
 *--------------------------------------------------------------------*
 ]Preamble]DA]SA]type]Length]PAD]DSAP]SSAP]Control]Information]PAD]FCS]
 *--------------------------------------------------------------------*
          ]Copy ]    Discard    ]<-----------Copy------------>]
          ]     ]               ]                             ]
          V     V    Insert     V                             V
 *----------------------------------------------------------------------*
 ]SD]AC]FC]DA]SA] Routing Info. ]DSAP]SSAP]Control]Information]FCS]ED]FS]
 *----------------------------------------------------------------------*

 Token-Ring

 The Ethernet Type field has a value x'80D5' to indicate LLC-on-Ethernet.

 -------------------------------------------------------------------------------
 Figure 110. LLC-on-Ethernet/Token-Ring Frame Conversion

 6.7.5.1.4  IEEE 802.3 - Token-Ring:  Token-ring to IEEE 802.3 conversion is
 accomplished even more simply.  See Figure 111 under heading "6.7.5.1.4  IEEE
 802.3 - Token-Ring".
 -------------------------------------------------------------------------------

 Token-Ring

     *-------------------------------------------------------------*
     ]SD]AC]FC]DA]SA]  RI  ]DSAP]SSAP]Control]Information]FCS]ED]FS]
     *-------------------------------------------------------------*
              ]     ] Cut  ]                             ]
              ]Copy ]      ]<-----------Copy------------>]
              V     VInsertV                             V
 *---------------------------------------------------------------*
 ]Preamble]SFD]DA]SA]Length]DSAP]SSAP]Control]Information]PAD]FCS]
 *---------------------------------------------------------------*

 IEEE 802.3

 IEEE 802.3

 *---------------------------------------------------------------*
 ]Preamble]SFD]DA]SA]Length]DSAP]SSAP]Control]Information]PAD]FCS]
 *---------------------------------------------------------------*
              ]     ] Cut  ]<-----------Copy------------>]
              ]Copy ]      ]                             ]
              V     VInsertV                             V
     *-------------------------------------------------------------*
     ]SD]AC]FC]DA]SA]  RI  ]DSAP]SSAP]Control]Information]FCS]ED]FS]
     *-------------------------------------------------------------*

 Token-Ring

 -------------------------------------------------------------------------------
 Figure 111. Token ring/IEEE 802.3/Token-Ring Frame Conversion

 6.7.5.1.5  ARP and RARP:  The 8209 also has the ability to convert frames that
 conform to the Address Resolution Protocol (ARP) and the Reverse Address
 Resolution Protocol (RARP).  Conversion is not always necessary and depends
 upon the interpretation of the protocol.
 ARP frames are used by TCP/IP in request from a server a stations MAC address
 when only its Internet address is known.
 RARP is used by a station to find out its own Internet address from a server
 machine. ARP and RARP packets have defined Ethernet type fields, (x'0806' and
 x'8035' respectively); the contents of the information field are also defined.

 6.7.6  The Utility Program
 This program, shipped with every 8209 that includes an Ethernet attachment
 module is designed to run under PC DOS (with LAN Support Program) or OS/2
 Extended Edition.  It allows the following unique 8209 parameters to be
 defined, displayed and modified from a token-ring attached station:
 o   The Spanning tree parameters
 o   Operational mode - mode 1, mode 2, automatic
 o   Enable/disable early token release - token-ring port at 16Mbps.
 o   Filter Definitions - it is possible to setup the 8209 such that certain
     frames will not pass across the bridge, thus reducing unnecessary traffic.
     The most common use of this facility would be to filter on a protocol
     basis; for example, only let TCP/IP frames pass across the bridge.
 o   Add/Delete Ethernet/IEEE 802.3 static database entries
 o   Examine Ethernet/IEEE 802.3 port statistics, for example the number of
     frames in error, number of collisions.
 o   Define bridge and emulated ring numbers.
 o   Define mapping of Ethernet and token-ring addresses.

 6.7.7  Configuration Switches
 The IBM 8209 has five switches on the Ethernet attachment module.  These are
 used to set:
 o   Token-ring speed - may be set for 4Mbps or 16Mbps operation.  If set for
     16Mbps, then early token release is enabled.
 o   Enable/disable automatic mode selection. If enabled, the 8209 will
     determine which frame format (Ethernet V2 or IEEE 802.3) a station on the
     Ethernet/IEEE 802.3 port is using.
 o   Mode 1/mode 2 priority operation. The operation of these switches is
     dependant on the setting of the Automatic Mode Switch.
     MODE 1
           Token-Ring to Ethernet V2
     MODE 2
           Token-Ring to IEEE 802.3
 o   Two switches: Initial Bridge number/Initial Ring number. These two
     switches are used to set values in combination.
 For further information the reader should consult the IBM 8209 CUSTOMER
 INFORMATION MANUAL shipped with every machine.

 6.7.8  Token-Ring Management Support
 As has been mentioned, the IBM 8209 is viewed by token-ring stations as a
 normal token-ring bridge. This also means that it is able to provide the
 management functions of token-ring bridges.  To that extent, the 8209
 implements on its token-ring port the following functions:
 o   LAN bridge server
 o   Ring parameter server
 o   LAN reporting mechanism.
 These server functions are described in "6.4 Bridge LAN Management Interface."

 6.7.9  Enhanced Ethernet Attachment Feature
 IBM has announced a new feature for the 8209 that increases the management
 capability of the device for token-ring segments, particularly when
 token-rings are being bridged to an Ethernet backbone.  The new feature can be
 installed in existing 8209s by replacing the old Ethernet attachment module
 with the new feature.
 o   Ring Error Monitor (REM)

     This enables the 8209 to receive MAC frames from token-ring attached
     stations that are reporting errors. The information can be sent on to the
     LAN Manager station on the network.
 o   Configuration Report Server (CRS)

     The IBM 8209 now implements this functional address on its token-ring
     port. Therefore, for configurations such as Figure 112 under heading
     "6.7.9  Enhanced Ethernet Attachment Feature", the 8209 is able to report
     token-ring stations attaching to the LAN.
 -------------------------------------------------------------------------------

  *-------------*                                     *-------------*
  ]             ]  *------*              *------*     ]             ]
  ] Token-Ring  ]--] 8209 ]--* ]      *--] 8209 ]-----] Token-Ring  ]
  ]     A       ]  ]   A  ] -------------]  B   ] A   ]     B       ]
  *-------------*  *------*        ]     *------* ]   *-------------*
        ]                      Ethernet     A     ]
     *-----*                                ]    CRS
     ] LAN ] <---------reporting link-------*    REM
     ] Mgr ]
     *-----*

   8209 A and B have the Enhanced Ethernet Feature installed

 -------------------------------------------------------------------------------
 Figure 112. 8209 Ethernet Backbone - Enhanced Token-Ring Management

     With the Enhanced Ethernet Feature, the Configuration Report Server
     function is enabled on 8209 "B". Adapters accessing token-ring "B" are now
     reported to the LAN Manager.
 o   Support of locally administered addresses on the 8209 ports.
 o   Enhanced Filtering

     The filtering capability of the IBM 8209 is improved and provides the
     ability to filter frames on Destination and Source Address, and a two byte
     data field.  You cannot filter frames on NETBIOS name or the number of
     link stations being used.
 o   Additionally, IBM LAN Manager Version 2.0 or above is able to to maintain
     a reporting link with 8209s across an Ethernet backbone by supporting use
     of the LAN Management SAP, x'F4', through the existing LLC-on-Ethernet
     function of the 8209.
 o   New functions are supported by an enhanced utility program.

 6.7.10  Summary
 The IBM 8209:
 o   When connected between two token-ring LANs:
     -   Is a standalone source-routing bridge
     -   Does not require a keyboard or display unit
     -   Has the function and filtering capabilities of the IBM Token-Ring
         Bridge Program V2.2
     -   Is fully compatible with IBM LAN Network Manager
     -   Improves performance over the Token-Ring Bridge Program
 o   When configured for Ethernet/IEEE 802.3 to token-ring bridging:
     -   Is a standalone LAN bridge between an Ethernet/IEEE 802.3 and a
         token-ring LAN.
     -   Is seen by stations on the Ethernet/IEEE 802.3 LAN as a transparent
         bridge, and by stations on the token-ring as a source routing bridge
     -   Can pass user information transparently between the LANs, providing
         frame conversion where necessary
     -   Supports communication between stations that use the Sub Network
         Access Protocol, LLC-on-Ethernet, or the IEEE 802.2 Logical Link
         Control.

         These protocols are used by TCP/IP, OSI, SNA and NETBIOS.  Access from
         Ethernet/IEEE 802.3 LAN attached stations to IBM AS/400, IBM RS/6000
         and IBM S/370 main frames (via gateways) is enabled.
     -   Allows peer-to-peer communication between workstations attached to
         both LANs. IBM provides support for Ethernet/IEEE 802.3 attached IBM
         Personal Computers and IBM Personal Systems/2 workstations in OS/2
         Extended Edition 1.2 with Etherand support, LAN Support Program 1.2.,
         as well as in the RS/6000 RISC range of processors and the IBM 6150
         PC-RT, using SNA, TCP/IP and NETBIOS.
     -   Means that token-ring technology can be used to provide high speed,
         high throughput, LAN backbones, providing an efficient, high
         performance, single image local area network.
     -   Can be managed using the architected management protocols of IEEE
         802.5, and hence by the IBM LAN Manager Version 2.0 or above.  Full
         token-ring management capability is available in conjunction with the
         Enhanced Ethernet Feature.
     -   Is shipped with a utility program that allows setting of all the
         bridge parameters.

 6.8  IBM Bridge Products Coexistence and Migration
 The IBM Token-Ring Network Bridge Program Version 1.0 and the IBM Token-Ring
 Network Bridge Program V1.1 can coexist in a multi-segment network with the
 IBM Token-Ring Network Bridge Program V2.0, the IBM Token-Ring Network Bridge
 Program V2.1, the IBM Token-Ring Network Bridge Program V2.2, the IBM 8209 LAN
 Bridge and the IBM PC Network Bridge Program.
 However, to take advantage of the dynamic maintenance capability of the
 single-route broadcast path, all bridges (with the exception of IBM 8209 LAN
 Bridge) in the multi-segment network must be running either the IBM Token-Ring
 Network Bridge Program V2 or the IBM PC Network Bridge Program, since only
 those bridge products can be configured for automatic maintenance.
 The IBM Token-Ring Network Bridge Program Version 1.0, now withdrawn from
 marketing, has no functional capability to communicate with a LAN Manager.
 The IBM Token-Ring Network Bridge Program V2.0, IBM Token-Ring Network Bridge
 Program V2.1 IBM Token-Ring Network Bridge Program V2.2, IBM 8209 LAN Bridge
 and IBM PC Network Bridge Program all communicate exclusively with IBM LAN
 Manager V2.0 and IBM LAN Network Manager, providing extended network
 management capabilities as explained in "9.0 LAN Management and Recovery."
 One IBM LAN Manager V2.0 can maintain up to 64 concurrent reporting links with
 any combination of these bridge products, while an IBM LAN Network Manager can
 have a link to 255 bridges.
 In today's large multi-segment LANs, full management capability, coupled with
 the greatest connectivity is offered by the latest releases of the bridge and
 LAN Management programs. This means that IBM Token-Ring Network Bridge Program
 V2.2, IBM PC Network Bridge Program, IBM 8209 LAN Bridge and IBM LAN Network
 Manager should become the products of choice for customers. Migrating these
 products to new releases, as and when they are announced, should become an
 accepted customer strategy.

 6.9  Routers

 6.9.1  The IBM LAN to LAN Wide Area Network Program
 Since the early days of the IBM PC Network (Broadband), application programs,
 such as the IBM PC Network Program and later the IBM PC LAN Program have
 provided file-sharing and print-serving capabilities as well as requester
 functions. The protocol that they used to communicate with each other over the
 LAN was NETBIOS, which also provided a simple "session layer" programming
 interface. NETBIOS is now accepted as an industry standard, with many hundreds
 of PC/LAN applications written to use it.  NETBIOS is still the protocol that
 is used to connect the latest high-performing IBM LAN Server Program Version
 1.2 to its requester machines. Although NETBIOS is no longer the IBM strategic
 interface or protocol for use in today's distributed data and application
 environment, the need to support it both on the local LAN and between
 geographically separate LANs remains strong.  Further information on NETBIOS
 can be found in "5.6.1.2 NetBIOS Interface."
 The IBM LAN to LAN Wide Area Network Program is a ROUTER  product that is
 designed to link geographically separate LANs together to carry NETBIOS
 traffic between them.  When the NETBIOS stations attach to LANs in close
 geographical proximity, local bridges provide the most flexible approach to
 network design.  Other protocols besides NETBIOS are able to share the common
 resource of the bridge.
 When the LANs are too far apart to make use of local bridges, the question
 arises of what should be done to provide interconnection?  Many customers
 already have a wide area network (WAN) installed, based on either SNA or X.25
 switches. A WAN is usually designed to be a shared resource, and resulting
 cost savings may mean that "meshing" becomes an economic proposition. This
 approach has other significant benefits, such as providing multiple paths
 through the network, and hence resilience to failure of individual components.
 Could the LANs be linked over the existing WAN?
 A remote bridge is another option. However, it requires the installation of a
 dedicated telecommunications link between the LAN sites. This link cannot be
 shared with the SNA WAN facilities, and to "mesh" the various LAN sites may
 require many remote bridges with consequent costs and management implications
 for the associated links.  The IBM token-ring remote bridge implementation
 does not allow for the link to cross a Packet Switched Data Network (PSDN)
 accessed with the X.25 protocol, a common WAN implementation. The IBM LAN to
 LAN Wide Area Network Program provides an answer to the question by allowing
 NetBIOS communications between LANs to share an SNA or X.25 WAN.

 6.9.1.1.1  General Description:  For the purposes of this discussion, where
 the context permits, an installed copy of the IBM LAN to LAN Wide Area Network
 Program is referred to as a NetBIOS switch.
 The IBM LAN to LAN Wide Area Network Program (a NetBIOS switch):
 o   Allows existing LAN-attached NetBIOS stations to communicate via a WAN.
 o   Is able to use an SNA backbone (SNA subarea or SNA Advanced Peer-to-Peer
     (APPN)) network or an X.25 Packet Switched Data Network (PSDN) as the WAN.
 o   Is an application designed to run on a Personal Computer or Personal
     System/2 machine under the OS/2 Extended Edition Version 1.2.  operating
     system.
 o   Has been designed to use the OS/2 Extended Edition Communication Manager
     Advanced Peer-to-Peer Communication (APPC) LU6.2 interface to send and
     receive traffic between NetBIOS switches.
 o   Supports one-to-many and many-to-one NetBIOS switch configurations.
 o   Provides a graphical and text based operator interface for planning,
     configuration, installation, monitoring, error detection and recovery.
 Figure 113 under heading "6.9.1.1.1  General Description" shows a simple
 configuration.
 -------------------------------------------------------------------------------

                        *------------*
                        ]    WAN     ]
 *-----*                ]            ]                *-----*
 ]NBIOS]  *---------*   ]            ]   *---------*  ]NBIOS]
 ]Stn. ]--]   LAN   ]   ]--*      *--]   ]   LAN   ]--]Stn. ]
 ]A1 <.........     ]   ]GW]      ]GW]   ]     .........> B1]
 *-----*  ]   .     ]   ]  ]      ]  ]   ]     .   ]  *-----*
          ]   .     ]   ]  ]      ]  ]   ]     .   ]
 *-----*  ]   .   ##########################   .   "  *"""""*
 ]A2 <.........   # ]   ]  ]      ]  ]   ] #   .........> B2]
 ]NBIOS]--]  ..   # ]   ]--*      *--]   ] #   ..  ]--]NBIOS]
 ]Stn. ]  *--..---#-*   ]            ]   *-#---..--*  ]Stn. ]
 *-----*     .. ] #     ]            ]     # ] ..     *-----*
            *..---#-*   ]            ]    *#---..-*
            ]..   # ]   ]            ]    ]#   .. ]
            ]VV   V ]   ]            ]    ]V   VV ]
            ]       ]   *------------*    ]       ]
            ]LAN-LAN]                     ]LAN-LAN]
            ]WAN pgm]                     ]WAN pgm]
            *-------*                     *-------*
            switch A                      switch B

    <------------>                          <------------>
       Region A                                Region B

    <###> LU 6.2 session

    <...> 802.2 Connection

    NBIOS       Station running NetBIOS application
    Stn.

 -------------------------------------------------------------------------------
 Figure 113. Connection of LANs via a WAN using IBM LAN to LAN Wide Area Network
             Program
 In this diagram, a  NetBIOS application in station A1 is communicating with a
 partner in station B1. Station A1 might be a DOS LAN Requester accessing a
 file server in station B1. At the same time, station A2, perhaps a print
 server, is being accessed by station B2.  Both connections are multiplexed
 onto an APPC LU 6.2 SNA session between the two NetBIOS switches. In fact,
 there actually are two LU 6.2 sessions and conversations between the switches,
 though only one is shown. One of these sessions is used for sending data
 between switch A and switch B, the other for data travelling in the opposite
 direction.
 The diagram indicates that the LANs, with their respective NetBIOS switches
 can be termed a REGION.  A region is a self-contained group of LAN segments
 connected together by MAC level bridges. Within a region, station MAC
 addresses and segment numbers must be unique. When regions are connected
 together with NetBIOS switches, segment numbers and MAC addresses may be
 duplicated between regions. This is an important migrational benefit, since
 when regions are to be connected for the first time, a major renumbering task
 may not be required.  If the regions were to be connected by a remote bridge,
 then uniqueness would be a requirement. The regions would be merged into one.
 The IBM LAN to LAN Wide Area Network Program supports multiple connectivity
 options.  On the LAN side the following are supported:
 o   IBM Token-Ring
 o   IBM PC Network (Broadband and Baseband)
 o   Ethernet.
 On the WAN side, any communication method that can be used by OS/2 Extended
 Edition 1.2 for APPC is supported. This includes all three LAN types described
 above, as well as:
 o   Synchronous Data Link Control (SDLC), using the standard IBM PC or PS/2
     line driver cards.  This link could run directly to another NetBIOS
     switch, to an SNA Communications Controller, to an IBM 9370 or an IBM
     AS/400 processor.
 o   CCITT X.25 using the appropriate PC or PS/2 card and interfacing to a
     public or private PSDN.
 MANY-TO-ONE or ONE-TO-MANY
 A NetBIOS switch is capable of having LU6.2 sessions with many other switches.
 This means that when multiple regions are to be connected, only one copy of
 the IBM LAN to LAN Wide Area Network Program is needed in any region. However,
 if there are two switches in the same region, both cannot have sessions with
 one or more switches in another region. If they did, then a "parallel path"
 would exist between the two regions, and this is not supported. The reason for
 this will become clear later.  Reference should now be made to Figure 114
 under heading "6.9.1.1.1  General Description".

 -------------------------------------------------------------------------------

                                              *-------*
                                              ]LAN-LAN]
                          .... .              ]WAN pgm]  ]  ]  ]
                     ...        .             ]       ]--+--+--+-
                  . .             ..          ]switch ]  ]  ]  ]
     *-------*    .                  ....#####]   A   ]  Region A
     ]LAN-LAN]  .                        #... *-------*
     ]WAN Pgm]   .                       #     .
     ]       ]############   WAN         #      .
     ]switch ]    .      #               #      .
     ]   B   ]#### ...   ############### #     .
     *-------*   #   .....             # #   .
       -+-      #      ############# . #.#..
        ]       #      #  ...      # . # #
 Region ]       ###    #     .    .#   # #
 B   ] -+-        #    #      .  . #   # #   *-------*
   --+--*        *-------*       .  #  # #   ]LAN-LAN]
     ]           ]LAN-LAN]          #  # ####]WAN pgm]   *-------------*
                 ]WAN pgm]          #  #     ]       ]---]  Token-Ring ]
   *----------*  ]       ]          #  ######]       ]   *-------------*
   ]Token-Ring]--]switch ]          #########]  D    ]      Region D
   *----------*  ]   C   ]                   *-------*
     Region C    *-------*

 -------------------------------------------------------------------------------
 Figure 114. One-to-Many Configuration
 Figure 114 under heading "6.9.1.1.1  General Description" shows that a station
 on the token-ring in region D is able to communicate with a station in any of
 the other three regions, because the NetBIOS switch in region D has a session
 with each of the other switches.  However, no station in region B can
 communicate with any station in region A, since there is no session between
 NetBIOS switch B and NetBIOS switch A. Although there is a session between
 switch B and switch D and another from D to A, a "concatenated" connection is
 not supported.

 6.9.1.1.2  The LU 6.2 Sessions:  The purpose of the LU 6.2 sessions is to
 provide a 'pipe' for communication between the NetBIOS switches.  This pipe is
 used for NetBIOS data transport between one LAN and the other, for setting up
 the communications path between the NetBIOS applications, and for internal
 communication between the switches for flow control and error information.
 Between any two switches, there are two sessions, one for transmitting data,
 the other for receiving data. The purpose of this implementation is to make
 the data path between the switches full duplex.
 The sessions are able to provide reliable data transport over the WAN, as well
 as being able to use SNA pacing to provide a flow control mechanism.  A
 "pacing function", using the 802.2 logical link control is also provided
 between the switches and the stations within their region.  This ensures that
 no part of the connection path can become over-congested with data.
 The APPC sessions are configured using the facilities of OS/2 EE 1.2
 Communication Manager. A single logical unit (LU) is defined, with the
 capability for this LU to have LU-LU sessions with multiple partners.
 The IBM LAN to LAN Wide Area Network Program is defined so as to have
 knowledge of its own LU, its own region, and the LU names of its partners. The
 region name of the partner is learned when the partner session is established.
 The LU sessions can be permanent, started automatically when the program is
 initialized, or temporary, that is started by operator command. If the partner
 switch is not active when session initialization is attempted, and the session
 is permanent, then the session will be retried.  If the partner switch is not
 active when session initialization is attempted, and the session is temporary,
 the initiating switch will wait for the partner switch to initiate the
 session.
 The status of the sessions can be displayed from the operator's screen,
 together with operational statistics.

 6.9.1.1.3  WAN Connectivity:  The following text in association with
 Figure 115 under heading "6.9.1.1.4  Direct switch to switch Connection"
 through Figure 119 under heading "6.9.1.1.5  Connection using a Backbone WAN"
 shows some of the WAN connectivity options open to users of the NetBIOS
 switch.

 6.9.1.1.4  Direct switch to switch Connection:  In this example, NetBIOS
 switches are connected together with a single leased line.
 -------------------------------------------------------------------------------
 SDLC LINK

                 <-APPC-->                   <-APPC-->
      *----------------------*  Session  *----------------------*
      ]   ]      ] --+---+---+-----------+---+---+-> ]      ]   ]
      ] N ] LAN  ]   ]   ]   ]  LU 6.2   ]   ]   ]   ] LAN  ] N ]
      ] E ] to   ]   ] P ] S ]           ] S ] P ]   ] to   ] E ]
   L  ] T ] LAN  ] L ] U ] D ]-----/     ] D ] U ] L ] LAN  ] T ]  L
   A<-] B ]      ] U ] 2 ] L ]   /-------] L ] 2 ] U ]      ] B ]->A
   N  ] I ] WAN  ]   ] . ] C ]           ] C ] . ]   ] WAN  ] I ]  N
      ] O ] pgm. ]   ] 1 ]   ]           ]   ] 1 ]   ] pgm. ] O ]
      ] S ]      ]   ]   ]   ]  LU 6.2   ]   ]   ]   ]      ] S ]
      ]   ]      ] <-+---+---+-----------+---+---+-- ]      ]   ]
      *----------------------*  Session  *----------------------*

 -------------------------------------------------------------------------------
 Figure 115. Direct Connection - SDLC
 It is only possible to connect two NetBIOS switches together in this way,
 since the SDLC link is ONLY supported as a  point-to-point link under OS/2.
 OS/2 Extended Edition can support up to two SDLC links, (by installing two
 multiprotocol adapter cards), which means that if direct links are being used,
 it is only possible for one switch to communicate with two others. The
 simplest topology that can illustrate this is the triangle of three switches,
 each with a link to the other two.
 The speed of the SDLC link is limited to 19.2Kbps.
 -------------------------------------------------------------------------------
 X.25

      *----------------------*  Session  *----------------------*
      ]   ]      ] --+---+---+-----------+---+---+-> ]      ]   ]
      ] N ] LAN  ]   ]   ] X ]           ] X ]   ]   ] LAN  ] N ]
      ] E ] to   ]   ] P ] . ]           ] . ] P ]   ] to   ] E ]
   L  ] T ] LAN  ] L ] U ] 2 ]---X.25    ] 2 ] U ] L ] LAN  ] T ]  L
   A<-] B ]      ] U ] 2 ] 5 ]  Network--] 5 ] 2 ] U ]      ] B ]->A
   N  ] I ] WAN  ]   ] . ]   ]           ]   ] . ]   ] WAN  ] I ]  N
      ] O ] pgm. ]   ] 1 ] V ]           ] V ] 1 ]   ] pgm. ] O ]
      ] S ]      ]   ]   ] C ]           ] C ]   ]   ]      ] S ]
      ]   ]      ] <-+---+---+-----------+---+---+-- ]      ]   ]
      *----------------------*  Session  *----------------------*

 -------------------------------------------------------------------------------
 Figure 116. Direct Connection - X.25
 One X.25 virtual circuit is required for each switch-to-switch connection.
 However, since these virtual circuits can be multiplexed onto a single leased
 link to the X.25 network, one switch may simultaneously connect to many
 others.
 In order to use X.25, the SDLC adapter is replaced by an IBM X.25
 Co-Processor/2 card for a Micro-Channel Architecture Personal System/2
 machine. Link speed can be 64Kbps maximum.

 6.9.1.1.5  Connection using a Backbone WAN:  If using SDLC links to an IBM
 Communications Controller with NCP, a scenario is illustrated in Figure 117
 under heading "6.9.1.1.5  Connection using a Backbone WAN".
 When using an SNA subarea network, many switches can be supported because of
 the routing ability of the SNA backbone.
 In the following diagrams the sessions between the NetBIOS switches have been
 shown as one, for the sake of clarity. All sessions are of course routed
 through the Communication Controllers containing the NCP.
 In order to support the IBM LAN to LAN Wide Area Network Program and APPC as
 INDEPENDENT LUS ACF/VTAM is required to be at Version 3.2 or above, with
 ACF/NCP at level Version 5.2 or above for the IBM 3745 and 3720 controllers,
 and Version 4.3 for the IBM 3725.
 -------------------------------------------------------------------------------
 USING IBM COMMUNICATIONS CONTROLLERS

                 LAN                             LAN
                  A                               A
                  ]                               ]
          *----------------*              *----------------*
          ]    NetBIOS     ]              ]    NetBIOS     ]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]A     LU      AA]              ]AA    LU       A]
          ]+-------------++]              ]++-------------+]
          ]]   PU 2.1    ]]]              ]]]  PU 2.1     ]]
          ]+-------------++]              ]++-------------+]
          ]] SDLC or LAN ]]]              ]]] SDLC or LAN ]]
          *+-------------++*              *++-------------+*
           ]      ]      ]*----------------*]     ]       ]
 ----*     ]      ]      *------------------+-----+------*]
     ]     ] *---------*                    ]*---------* ]]
  V  ]     ] ]         ]-----------/        ]]         ] ]]
  T  ]- - -]-]   NCP   ]          /---------+]   NCP   ] ]]
  A  ]     ] ]         ]                    ]]         ] ]]
  M  ]     ] *---------* *------------------**---------* ]]
     ]     ]      ]      ]*----------------*      ]      ]]
 ----*     ]      ]      ]]                ]      ]      ]]
          *+-------------++*              *+-------------++*
          ]] SDLC or LAN ]]]              ]] SDLC or LAN ]]]
          ]+-------------++]              ]+-------------++]
          ]]   PU 2.1    ]]]              ]]   PU 2.1    ]]]
          ]+-------------++]              ]+-------------++]
          ]V     LU      VV]              ]V     LU      VV]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]    NetBIOS     ]              ]    NetBIOS     ]
          *----------------*              *----------------*
                  ]             LU 6.2            ]
                  V           <-------->          V
                 LAN           Sessions          LAN
 -------------------------------------------------------------------------------
 Figure 117. SNA Subarea Network
 The NCPs could be replaced by an IBM 9370, its Integrated Communication
 Adapter and VM/9370 Version 3.3
 Almost identical pictures can be drawn for connection across an X.25 network.
 The 37xx/NCP must now contain NCP Packet Switching Interface (NPSI), and the
 SDLC link in the NetBIOS switches is replaced by an X.25 virtual circuit.
 NPSI must be at a level compatible with the NCP installed.
 In this example, the SNA subarea network is accessed via an X.25 network.
 Routing for the APPC sessions, is still dependent on the capabilities of the
 SNA subareas. The scenario is illustrated in Figure 118 under heading
 "6.9.1.1.5  Connection using a Backbone WAN".
 -------------------------------------------------------------------------------
 SNA OVER X.25

                 LAN                             LAN
                  A                               A
                  ]                               ]
          *----------------*              *----------------*
          ]    NetBIOS     ]              ]    NetBIOS     ]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]A     LU      AA]              ]AA    LU       A]
          ]+-------------++]              ]++-------------+]
          ]]   PU 2.1    ]]]              ]]]  PU 2.1     ]]
          ]+-------------++]              ]++-------------+]
          ]]   X.25 VC   ]]]              ]]]  X.25 VC    ]]
          *+-------------++*              *++-------------+*
           ]      ]      ]]                ]]     ]       ]
           ]     X.25    ]*----------------*]    X.25     ]
 ----*     ]      ]      *------------------+-----+------*]
     ]     ] *---------*                    ]*---------* ]]
  V  ]     ] ]   NCP   ]                    ]]   NCP   ] ]]
  T  ]- - -]-]  NPSI   ]-----X.25 Network---+]  NPSI   ] ]]
  A  ]     ] ]         ]                    ]]         ] ]]
  M  ]     ] *---------* *------------------**---------* ]]
     ]     ]      ]      ]                        ]      ]]
 ----*     ]     X.25    ]*----------------*     X.25    ]]
           ]      ]      ]]                ]      ]      ]]
          *+-------------++*              *+-------------++*
          ]]   X.25 VC   ]]]              ]]   X.25 VC   ]]]
          ]+-------------++]              ]+-------------++]
          ]]   PU 2.1    ]]]              ]]   PU 2.1    ]]]
          ]+-------------++]              ]+-------------++]
          ]V     LU      VV]              ]V     LU      VV]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]    NetBIOS     ]              ]    NetBIOS     ]
          *----------------*              *----------------*
                  ]                               ]
                  V                               V
                 LAN                             LAN
 -------------------------------------------------------------------------------
 Figure 118. SNA Subarea Network over X.25
 Another alternative is to use an SNA Advanced Peer-to-Peer network.  This is
 currently implemented with the IBM AS/400 system and is shown in Figure 119
 under heading "6.9.1.1.5  Connection using a Backbone WAN".
 -------------------------------------------------------------------------------
 AS/400 APPN

                 LAN                             LAN
                  A                               A
                  ]                               ]
          *----------------*              *----------------*
          ]    NetBIOS     ]              ]    NetBIOS     ]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]A     LU      AA]              ]AA    LU       A]
          ]+-------------++]              ]++-------------+]
          ]]   PU 2.1    ]]]              ]]]  PU 2.1     ]]
          ]+-------------++]              ]++-------------+]
          ]] SDLC or LAN ]]]              ]]] SDLC or LAN ]]
          *+-------------++*              *++-------------+*
           ]      ]      ]*----------------*]     ]       ]
           ]      ]      *------------------+-----+------*]
           ] *---------*                    ]*---------* ]]
           ] ]         ]----------/         ]]         ] ]]
           ] ] AS/400  ]         /----------+] AS/400  ] ]]
           ] ]         ]                    ]]         ] ]]
           ] *---------* *------------------**---------* ]]
           ]      ]      ]*----------------*      ]      ]]
           ]      ]      ]]                ]      ]      ]]
          *+-------------++*              *+-------------++*
          ]] SDLC or LAN ]]]              ]] SDLC or LAN ]]]
          ]+-------------++]              ]+-------------++]
          ]]   PU 2.1    ]]]              ]]   PU 2.1    ]]]
          ]+-------------++]              ]+-------------++]
          ]V     LU      VV]              ]V     LU      VV]
          ]----------------]              ]----------------]
          ]LAN-LAN WAN pgm.]              ]LAN-LAN WAN pgm.]
          ]----------------]              ]----------------]
          ]    NetBIOS     ]              ]    NetBIOS     ]
          *----------------*              *----------------*
                  ]                               ]
                  V                               V
                 LAN                             LAN
 -------------------------------------------------------------------------------
 Figure 119. AS/400 Advanced Peer-to-Peer Network

 6.9.1.1.6  Determining the Target Region:  As has been discussed in "5.6.1.2
 NetBIOS Interface" NetBIOS uses NAMES  rather than MAC addresses for session
 support, and provides a set of services to locate and associate these names
 with network MAC addresses.  A NetBIOS requester, perhaps named PETE, wants to
 access resources located on a NetBIOS server with the name SRV.  When PETE
 wants to establish a session with SRV, a command will be sent on the network
 to find which station knows the name SRV. Once located, a session will be
 started, and data transferred. Names must therefore be unique.
 The command used for this initial search function is the NetBIOS NAME_QUERY ,
 and it is addressed to the NETBIOS FUNCTIONAL ADDRESS. Because the IBM LAN to
 LAN Wide Area Network Program has this address opened on it's LAN adapter, it
 is able to receive the NetBIOS Name_Query command.
 The NetBIOS switch then searches its user-defined FILTER AND TARGET RESOLUTION
 TABLE to determine if it needs to route the request, and if so to which
 region. The table has two purposes which are performed sequentially:
 1.  RESOLUTION  Determine the target region for a given name. If the name is a
     NetBIOS GROUP NAME, then there may be a need to route the request to
     multiple regions.
 2.  FILTERING  Given the target region(s) and name, determine whether the
     frame should be forwarded to the region or not.
 NAME RESOLUTION
 At each IBM LAN to LAN Wide Area Network Program, the user must configure a
 list of all the NetBIOS names on that region which are to be accessed by other
 regions.  To keep the user from having to determine the actual 16 character
 NetBIOS name (which may be significantly different than the application name),
 the names in the list have implicit wild cards at the beginning and end of the
 name.  For example, if the name PETE was entered in the list, destination name
 'PETER          ' and 'DOMAINxxPETE    ' would find a match.
 Again, the list is configured at the IBM LAN to LAN Wide Area Network Program
 on which the names reside.  When the IBM LAN to LAN Wide Area Network
 Program-to-IBM LAN to LAN Wide Area Network Program sessions are established,
 the list is passed to the partner IBM LAN to LAN Wide Area Network Program.
 When a NetBIOS NAME_QUERY or DATAGRAM frame is received at a IBM LAN to LAN
 Wide Area Network Program the destination name is matched against every name
 in every target region's list until a match is found or the list is exhausted.
 If a match is found, the frame is passed onto the target region.  Otherwise it
 is discarded.  The frame is NOT broadcast to all regions in search of the
 name.
 If only servers are to be accessed in a region, the name list could consist of
 each server name or just the domain name of a group of servers.  If
 peer-to-peer communications was desired, it may be necessary to rename all
 stations in a region to imbed a region qualifier in the name.  This region
 qualifier would then be added to the name list.
 FILTERING
 The filter function gets control on each broadcast frame to a specific name or
 group name.  Its major function will be, given the target region for a frame,
 to determine whether the frame should be forwarded to that region or filtered.
 The filter routine will be a dynamic link routine external to the rest of the
 IBM LAN to LAN Wide Area Network Program product.  The interface to the filter
 will be published so that a customer can write and install his own filter
 routine tailored to the particular network needs.
 In addition, the IBM LAN to LAN Wide Area Network Program will provide on the
 shipped diskette a general purpose filter routine.

 6.9.1.1.7  NetBIOS Session Setup
 -------------------------------------------------------------------------------

    *------*    *------*            *------*    *------*
    ] PETE ]    ]switch]----------->]switch]    ] SRV  ]
    ]      ]<-->]      ]    WAN     ]      ]<-->]      ]
    ]      ]LAN ]      ]<-----------]      ] LAN]      ]
    *------*    *------*            *------*    *------*

 Name_Query -------->
 (Step 1 under heading "6.9.1.1.7  NetBIOS Session Setup")
                 Table (Step 2 under heading "6.9.1.1.7  NetBIOS Session Setup")
                 Search

                    ------------------->
                       Name-Query (Step 3 under heading "6.9.1.1.7  NetBIOS Sess
                                       ------------>
                                          (Step 4 under heading "6.9.1.1.7  NetB

                                       <------------
                    <-------------------
       <-------------   Name_Recognized
                           (Step 5 under heading "6.9.1.1.7  NetBIOS Session Set
                                  LLC
                                Connect------------>
   LLC                                    (Step 6 under heading "6.9.1.1.7  NetB
 Connect------------>
                                       <------------
 (Step 7 under heading "6.9.1.1.7  NetBIOS Session Setup")
        <------------

       -------------------------------------------->
                  Session_Initialize

                       (Step 8 under heading "6.9.1.1.7  NetBIOS Session Setup")

       <--------------------------------------------
                   Session_Confirm

       <------------------------------------------->
                      Data Flow

    *------*    *------*            *------*    *------*
    ] PETE ]    ]switch]----------->]switch]    ] SRV  ]
    ]      ]<-->]      ]    WAN     ]      ]<-->]      ]
    ]      ]LAN ]      ]<-----------]      ] LAN]      ]
    *------*    *------*            *------*    *------*
     ]<----------->] ]<------------->]  ]<----------->]
      802.2 Circuit    LU6.2 session     802.2 Circuit

     ]<---------------------------------------------->]
                    NetBIOS SESSION
 -------------------------------------------------------------------------------
 Figure 120. NetBIOS Session Initiation Flow across a WAN
 We will now describe what happens when a cross-WAN NetBIOS session is to be
 setup. Reference can be made to Figure 120 under heading "6.9.1.1.7  NetBIOS
 Session Setup" which shows the flows, together with a pointer to the
 descriptive text.
 1.  When the NetBIOS Requester with the name PETE wishes to establish a
     session with the NetBIOS server SRV, PETE's NetBIOS application will send
     a NAME_QUERY  command as a Single-Route Broadcast frame addressed to the
     NetBIOS functional address. The frame will include the name SRV, with the
     expectation that a station will recognize the name and respond.
 2.  Since IBM LAN to LAN Wide Area Network Program has opened the NetBIOS
     functional address it will receive commands sent to the NetBIOS functional
     address, and search the resolution table to determine if the name is
     defined, and in what region it lies.  Determining the region that a
     NetBIOS name is associated with is done on an LU 6.2 session basis.  So if
     one IBM LAN to LAN Wide Area Network Program is connected to several other
     IBM LAN to LAN Wide Area Network Programs, as that one IBM LAN to LAN Wide
     Area Network Program connects to another IBM LAN to LAN Wide Area Network
     Program the NetBIOS names that are forwarded would be associated with that
     particular LU 6.2 session.  That one IBM LAN to LAN Wide Area Network
     Program would have a Name Resolution table that would associate any given
     NetBIOS name to the LU 6.2 session that passed the name to it.
     Definitions at a local IBM LAN to LAN Wide Area Network Program would only
     be for those local NetBIOS names that would want to have access through
     the local IBM LAN to LAN Wide Area Network Program.  It is not necessary
     that any target NetBIOS names be known to the local IBM LAN to LAN Wide
     Area Network Program.
 3.  Assuming that the target NetBIOS name is found, and the request is not
     filtered out, the SOURCE  NetBIOS switch will forward the Name_Query to
     the TARGET switch over the appropriate pre-established LU 6.2 session.
 4.  The target switch then places the Name_Query message onto it's local LAN.
 5.  Assuming that SRV is active, a NAME_RECOGNIZED response will be returned
     via the switches to the originating station.
 6.   Reception of the Name_Recognized at the target switch causes it to
     initiate a connection-oriented logical link between itself and the target
     station, SRV.
 7.  The NetBIOS switch (source switch) in PETE's region passes the
     Name_Recognized back to PETE, giving the MAC address of SRV as the THE MAC
     ADDRESS OF THE SOURCE NETBIOS SWITCH, not the actual MAC address of SRV.
     PETE now starts a logical link between its own station and the source
     switch or local switch.

     This explains the reason why parallel NetBIOS switch paths are not
     supported between regions. If a parallel path existed, there would be two
     or more source switches. Both would forward the Name_Query to the target
     region, and both sources would provide responses. In effect, it would look
     as though SRV existed on the network twice, at two different MAC
     addresses. This condition is a violation of NetBIOS protocol.

     Note that the initiation of steps 6 and 7 occur simultaneously.
 8.  Once the logical link connection at the source end is completed a
     SESSION_INITIALIZE  is sent by PETE to SRV, and the SESSION_CONFIRM
     response indicates that data transfer can begin.
 The session is now established. The NetBIOS session flows end-to-end, between
 PETE and SRV. However, two logical links have been established, one between
 PETE and the source switch, the other between SRV and the target switch. Since
 the performance characteristics of the WAN are unknown, there is no
 implication on the logical links for timing problems or delays within the WAN,
 though adjustment of NetBIOS session timers may be required.
 One 802.2 logical link and several NetBIOS sessions from any one workstation
 are known as one 802.2 CIRCUITs. An 802.2 Circuit is an internal resource to
 the IBM LAN to LAN Wide Area Network Program.  There are a finite number of
 802.2 Circuits available.  When a station wants to establish a NetBIOS session
 with another station using the IBM LAN to LAN Wide Area Network Program, an
 802.2 logical link is established between the station and the local IBM LAN to
 LAN Wide Area Network Program.  A NetBIOS session is also established between
 each station.  One 802.2 Circuit is then allocated from the IBM LAN to LAN
 Wide Area Network Program workstation.  If the same station was to establish
 another NetBIOS session, it would use the one 802.2 Circuit that had already
 been established.  This permits the IBM LAN to LAN Wide Area Network Program
 to minimize the use of 802.2 link stations and allow more NetBIOS sessions
 across the WAN.

 6.9.1.1.8  Management

 6.9.1.1.9  Alert Management:  The IBM LAN to LAN Wide Area Network Program
 sends its alerts to the LAN Manager using the Alert Transport Facility of IBM
 LAN Manager V2 and IBM LAN Manager Entry or above. Since this facility does
 not use the NetBIOS protocol, a LAN Manager application must be present in
 each LAN region. This LAN Manager may of course be connected to NetView on a
 S/370 host for central management.
 Alerts are provided for:
 o   The defined number of 802.2 Circuits has been exceeded
 o   No more 802.2 link stations available
 o   Internal buffers depleted
 o   LU 6.2 session dropped
 o   IBM LAN to LAN Wide Area Network Program terminated.

 6.9.1.1.10   Operator Interface:  The operator of the IBM LAN to LAN Wide Area
 Network Program can modify some dynamic parameters without re-initializing the
 program, and obtain information about the following:
 o   The OS/2 EE Communication Manager configuration
 o   Fixed parameters of the switch configuration

     Includes LU Names, buffer sizes and numbers, LAN adapters used, and filter
     used.
 o   Dynamic configuration parameters

     Aging timers, warning thresholds, timing intervals for report logging
     logging and resolution table are examples.
 o   Problem determination and performance/utilization

     A range of counters, thresholds, status indicators and time/date
     information on:
     -   The switch itself
     -   LU 6.2 sessions
     -   NetBIOS sessions
     -   802.2 Circuits
     -   Errors
 o   Viewing the disk log

     A disk based log is an option of the IBM LAN to LAN Wide Area Network
     Program. Information may be placed in this file as a result of specific
     events, or at regular intervals.
 Facilities such as the OS/2 EE Communications Manager trace and message files
 are also available to assist with problem determination.

 6.9.1.1.11  Limitations:  The IBM LAN to LAN Wide Area Network Program has the
 following limitations:
 o   Each IBM LAN to LAN Wide Area Network Program cannot be configured for
     connection to more than 48 remote IBM LAN to LAN Wide Area Network
     Programs.
 o   The IBM LAN to LAN Wide Area Network Program must reside within the same
     workstation as the OS/2 EE V1.2 SNA gateway.
 o   Duplicate NetBIOS names should not be defined to the IBM LAN to LAN Wide
     Area Network Program or reside within the network.  A warning message will
     be issued.

 6.9.1.1.12  Summary:  The IBM LAN to LAN Wide Area Network Program:
 o   Provides a means for interconnecting LANs across a wide area network to
     convey NetBIOS traffic from one LAN to another.

     The WAN can be a SNA subarea network, an SNA APPN network, or an X.25
     network. An X.25 network must be capable of supporting Qualified Logical
     Link Control (QLLC - SNA over X.25).switches can be connected together by
     a dedicated link.
 o   Allows the NetBIOS traffic to share the bandwidth of the WAN with other
     traffic.
 o   Uses APPC LU6.2 sessions as "pipes" for the inter-regional NetBIOS
     traffic.
 o   Uses the facilities of OS/2 Extended Edition Communications Manager 1.2 to
     support the APPC LU 6.2 communications.
 o   Can attach to Ethernet, token-ring or PC Network (Broadband and Baseband)
     LANs.
 o   Is an OS/2 application, therefore need not run in a dedicated machine.
     NOTE:   If the machine is required to run another NetBIOS application
     apart from the IBM LAN to LAN Wide Area Network Program, the LAN adapter
     cannot be shared between the applications. Two adapters must be installed.
 o   Provides a region resolution and filter mechanism to control access to
     resources across the WAN. The filter is tailorable to customers' needs.
 o   Does not support "concatenated" or "parallel" connections between regions.
 o   Is provided with a set of utilities, allowing operator control, statistics
     gathering and comprehensive problem determination facilities.
 o   Is positioned for customers who have made an investment in their WANs and
     who do not wish to invest in the link costs of a remote bridging solution.
     The product should be used by customers who regard their inter-LAN NetBIOS
     traffic as a small percentage of their overall WAN traffic.  It is very
     suitable for those customers that only want to provide occasional access
     to NetBIOS resources through the WAN.